Hi Renato, Markus, Kevin et al
Should a dump file really have anything to do with TAPIR? I would have expected to see it external to TAPIR spec - not to say that the wrapper software can't be a TAPIR wrapper plus a 'dump file' wrapper at the same time.
Similarly with TAPIRLite - maybe I don't get it right, or perhaps it was the early adopters, but one can be a TAPIRLite provider while only answering one search URL pointing at a custom query template with say a couple of GET params passed in, only support a custom response schema, yet claim TAPIR compliance - is this technically correct?
What say you guys? Looking forward to discussing with you all.
Cheers from Singapore Airport,
Tim
Hi Markus,
Sorry about the delay - I've just returned from a workshop.
If I understood your suggestion correctly, all TAPIR providers would need to parse filters, understand search requests with the model parameter, and support inventories in any concepts. This means that query templates would not be necessary anymore, right?
I think it's quite a big change at this point and it will impact existing provider implementations that follow the current TAPIRLite approach.
If there's any serious interoperability problem now, we need to investigate it carefully before making this kind of change. I understand that raising the minimum service profile level can in principle make things easier for clients. But if this is going to make things too difficult for new provider implementations, one of the possible consequences is to see other protocols or even unofficial variations of TAPIR being used, which can be worse than having a single protocol with different service profiles.
What I do think we're missing is guidelines for different types of providers and networks. Simple documents, 1 or 2 pages, with clear recommendations such as what conceptual schemas, output models and query templates to use.
Some comments about your specific suggestions:
the inventory and search operation is optional. Is there a need for
services not supporting them?
We were probably too flexible when we made them optional. However, now that we're considering a change that will allow providers to advertise dump files, I'm just thinking if this can be acceptable: "here's my metadata, here's the conceptual schemas that I mapped and here's a dump file, but I still don't support inventories and searches". If we don't want to allow this, then at least the search operation could be mandatory. Or maybe both search and inventory, as you suggested.
any need for inventory operations not to support anyConcept?
I don't know if there's any TAPIR provider not supporting them (anyone here?). If not, perhaps we can change. Anyway, I think we still need to allow inventory templates for providers that won't support filters.
search operation should mandate at least 1 output model support
This is related with dropping TAPIRLite. I'm not convinced that this would be a good change.
cant concept, literal and parameter expressions in filters be mandatory? likewise cant logical operators and equals comparisons be mandatory
filter parts? what about greaterThan and lessThan?
I didn't understand this. Are you talking about capabilities or about the filter definition in the XML Schema? Can you give some example?
Best Regards,
Renato
PS: I'm traveling next week, so I may not be able to respond promptly. By the way, we can also discuss this during TDWG.
Dear all, I would like to discuss the optional bits of TAPIR capabilities again in the light of service interoperability, especially when dealing with TAPIR lite. Do we really need to have so many optional capabilities for TAPIR? I do firmly think this is causing more problems than benefits and would prefer more mandatory capabilities. In particular I think TAPIR model support should be the lowest common denominator and not only templates as it is currently for TAPIR lite.
Do the following capabilities really need to optional?
- the inventory and search operation is optional. Is there a need for
services not supporting them?
- any need for inventory operations not to support anyConcept?
- search operation should mandate at least 1 output model support
- cant concept, literal and parameter expressions in filters be
mandatory?
- likewise cant logical operators and equals comparisons be mandatory
filter parts? what about greaterThan and lessThan?
regards, Markus
tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir
____________________________________________________________ Tim Robertson Systems Architect Global Biodiversity Information Facility Secretariat (GBIF) Universitetsparken 15, 2100 Copenhagen Ø, Denmark http://www.gbif.org trobertson@gbif.org Phone: +45 35 32 14 87 (Office) Fax: +45 35 32 14 80 ____________________________________________________________