[tdwg-tapir] Interpretation of TAPIR filters
Renato De Giovanni
renato at cria.org.br
Fri Nov 23 02:53:02 CET 2007
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&species=y
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
More information about the tdwg-tag
mailing list