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?
Roger
On 23 Nov 2007, at 05:29, Renato De Giovanni wrote:
Hi Roger,
Does this mean that if I have a filter that specifies long, lat and altitude and a provider who has no notion of altitude
- requests that include the long, lat and alt parameters will return
matches for records with those longs and lats (the alt COP will have been dropped from the equals block)
No. If a request contains the parameters long, lat and alt, it will only get records from providers that have mapped all three underlying concepts. If a provider didn't map alt, you'll get no results back because the alt condition will evaluate to false.
- requests that include just long and lat parameters will match
nothing because the alt COP will evaluate to false.
No. Requests containing only long and lat will return records from all providers that mapped the two underlying concepts, even if they didn't map alt (in this case the alt condition will be dropped).
To get a result from a provider one has to define a parameter for a concept they don't map! If this is correct isn't it counter intuitive? Perhaps I have interpreted it wrongly. (long lat is probably a bad example)
Well, that proposal still makes sense to me, unless I'm missing something. The only thing, still using your example, is that if no parameters are passed, all conditions will be dropped, which means there will be no filter and you'll get all records back (truncated by the maximum element repetitions, of course). But I don't think this is a problem.
A related issue to this is sorting. It is not clear what the orderBy operator does because there are no data types in TAPIR concepts.
Concept data types are specified by the respective conceptual schema. The data types for ABCD or DarwinCore concepts, for example, are all well-defined by their XML Schemas. But if the conceptual schema is just a simple list in a CNS configuration file, with no other external definitions, then I agree it may be an issue. Perhaps we should recommend more explicitly that concepts will be better defined in a format which includes data types? (could even be just a simple list of global elements in an XML Schema).
Should the wrapper order results by the conceptual XML schema data type (if there is one) or the output model data type?
It should order results by the data type defined in the conceptual schema.
I can't see solutions for this because I can't see how a wrapper would implement alternative sorting mechanisms from the ones it knows i.e. the types of its columns. Perhaps the capabilities should indicate the data type the concepts are treated as e.g.
<mappedConcept id="http://example.net/redlist/DataSourceCode" alias="DataProviderCode" as="xsd:string" />
Meaning "We have mapped this concepts and we treat it like a string".
I like the idea, even if it will just repeat an information that can be found in the conceptual schemas. Not sure what the others think about this. But I would make this new attribute optional, for backwards compatibility and also considering possible class concepts in the future.
This problem grows when we think of data types that may be serialized in different ways (date is the only one I can think of). If I want all the records before a certain date how do I pass the date?
In this case you should pass a value compatible with the corresponding data type. If the data type somehow accepts values in different formats (for instance '2002-09-24Z' or '2002-09-24+06:00') then the provider should be able understand all these formats when processing the query.
Best Regards,
Renato _______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir