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
On Oct 6, 2008, at 16:14, Markus Döring (GBIF) wrote:
Renato, all proposals sound valuable and good to me. Working on my new TAPIR implementation I would like to propose another change. What do you think of removing the TAPIR lite option altogether and mandate tapir model support via KVP as the lowest option for compliant TAPIR services? I would at least have a discussion around this subject, as it effects TAPIR interoperability in networks a lot. And I think you didn't feel too comfortable when I said GBIF will implement TAPIRlite only. I am thinking of implementing model based TAPIR now because I see too many interoperability problems.
what do you think? can we put this on the agenda for discussion at least? Markus
On Oct 6, 2008, at 15:14, Renato De Giovanni wrote:
Dear all,
As mentioned in the last message, I created a new page in the Wiki to document possible changes in the protocol:
http://wiki.tdwg.org/twiki/bin/view/TAPIR/PossibleChanges
Please feel free to add your comments or suggest other changes. Use the Wiki or the mailing list.
If we decide to make any changes, they will be the last ones before submitting TAPIR to the TDWG standards track. I would also like to suggest October 31st as the deadline to decide about this.
Best Regards,
Renato
Dear all,
I finally managed to update the TAPIR specification to reflect the last issues discussed in this mailing list:
http://www.tdwg.org/dav/subgroups/tapir/1.0/docs/TAPIRSpecification_2008-09-...
I also updated the network builders' guide to include references to the new resources (TapirTester and TapirBuilder) and to recommend the new CNS encoding in XML instead of the old text file:
http://www.tdwg.org/dav/subgroups/tapir/1.0/docs/TAPIRNetworkBuildersGuide_2...
The official links are already redirecting to these documents.
I think it's time to consider submitting TAPIR to the TDWG standards track, but my feeling is that we should first wait for the annual meeting since we're close to it anyway. There's no subgroup meeting planned for TAPIR this year, but the TDWG annual meeting is always an opportunity for most people here to interact and to see if there are any specific improvements we should still make in the protocol.
I've been taking notes of additional changes that we could possibly make before finishing version 1.0. I'll try to organize this in the Wiki during the next days and I'll give you the link. We can then revise the list of possible changes and decide together what we should do.
Please let me know if you have any ideas about this. I think we should definitely finish TAPIR 1.0 this year and try to make it a TDWG standard.
Best Regards,
Renato
tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir