Dear all,
I came across an issue that I know it was discussed before, but I couldn't find anything about it in the spec and I couldn't find a message with a final agreement/solution.
The issue is: How should TAPIR filters be interpreted if they reference concepts that are not understood by providers or if they reference parameters that were not passed?
Query templates may often include parameterized filters with many conditions, such as:
<filter> <and> <equals> <concept id="http://rs.tdwg.org/dwc/dwcore/Genus"/> <parameter name="genus"/> </equals> <equals> <concept id="http://rs.tdwg.org/dwc/dwcore/SpecificEpithet"/> <parameter name="species"/> </equals> <equals> <concept id="http://rs.tdwg.org/dwc/dwcore/Country"/> <parameter name="country"/> </equals> </and> </filter>
And it's important to be able to use the same query template even when not all parameters are passed, such as allowing all these calls:
http://myprovider.org/tapir?op=search&t=mytemplate&genus=x
http://myprovider.org/tapir?op=search&t=mytemplate&genus=x&speci...
http://myprovider.org/tapir?op=search&t=mytemplate&country=z
and so on...
Otherwise we would need a different template for each combination of parameters, which would certainly make clients very unhappy.
I've been discussing this with Markus and we're leaning towards the following suggestion about how to interpret filters:
1- Comparative operators (COPs) that reference unspecified parameters should be simply dropped from the filter. 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. 3- After dropping a COP, if it was part of a logical operator (LOP) then the LOP should also be dropped if there are no boolean operators left inside the LOP. 4- After dropping a LOP, if it was part of another LOP, then the parent LOP should also be dropped if there are no boolean operators left inside the parent LOP.
There's clearly a gap in the specification about this and we need to fix it, so please let me know if you have any thoughts about this. If there are no objections or better suggestions, then I'll probably use the proposal above to amend the spec.
Many thanks! -- Renato