On 23 Nov 2007, at 01:53, Renato De Giovanni wrote:
2- COPs must evaluate to false if they reference a concept that is not understood by the provider, unless they also reference an unspecified parameter - in which case the COP must be dropped from the filter.
Does this mean that if I have a filter that specifies long, lat and altitude and a provider who has no notion of altitude
1) 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)
2) requests that include just long and lat parameters will match nothing because the alt COP will evaluate to false.
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)
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. Should the wrapper order results by the conceptual XML schema data type (if there is one) or the output model data type? 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".
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? One of the ISO standards? Unix timestamp? How do we handle granularity? etc. We don't define that anywhere and if the wrapper just takes the string value it is given and passes it to the database we might get different results from different RDMS or even errors.
Sorry to muddy the waters.
Roger