[tdwg-tapir] Interpretation of TAPIR filters
D ö ring, Markus
m.doering at BGBM.org
Tue Dec 4 10:48:11 CET 2007
Just catching up.
I agree with Renato about all the filter issues as you probably have
guessed. Regarding sorting now. In pywrapper I have left the "how" it gets
sorted to the underlying database type. And that might be very different to
the conceptual or model one. But I wonder if it is really important to be
specific about the sorting order? At least it is sorted in some stable way.
I agree it makes sense to announce that datatype in the capabilities, so you
understand the sorting. That can easily be done using xml schema datatypes
(should cover nearly all db types). The underlying datatype also affects
what COPs you can use with it. You will get an error with PyWrapper for
example if you do a LIKE on a date or integer type.
If we will force people to adapt their datatypes in the underlying database
this is quite a burden. This way every data provider will need a copy of
their database and they will never be able to use the original dataset. That
might not be a problem and in fact this allows you to do quite some data
transformation in between, but for many providers I know this will be too
much - or they will close to never update their data clone.
So for now I would suggest to indicate the underlying db type in the concept
capabilities and just use whatever there is for ordering. We should probably
come up with a standard error for the CopNotSupportedByLocalDatatype. How do
you deal with this in TapirLink Renato?
"Renato De Giovanni" wrote on 26.11.2007 2:18 Uhr:
> Hi Roger,
> Yes, I fully agree that the spec should be revised to be clearer
> about data types. I also like the idea of using "string" as a default
> data type. Let's just wait a bit more to see if there are other
> suggestions and opinions.
> Best Regards,
> On 23 Nov 2007 at 21:22, Roger Hyam wrote:
>> Hi Renato,
>> I think I follow you - but I'll probably believe it when I see it
>> spelled out in the spec.
>> I think some of the sorting stuff should be in the specification.
>> There are some things there that are implied but not expressed.
>> 1) schema concepts should/must only be mapped to columns of the same
>> data type in the host database or at least wrappers should act as if
>> they are.
>> 2) Values in queries (and parameters) should use the xsd serialization
>> of date (and other things?). It is the wrappers responsibility to
>> present the correctly to the underlying database.
>> 3) If the concept does not have a data type the behaviour of orderby,
>> greaterthan and lessthan are undefined? If we stick to XML Schema
>> concept schemas then they default to string so maybe the default
>> should be to act as string.
>> What do you think?
> tdwg-tapir mailing list
> tdwg-tapir at lists.tdwg.org
More information about the tdwg-tag