[tdwg-tapir] ideas & TapirLite

Donald Hobern dhobern at gbif.org
Thu Nov 17 16:56:47 CET 2005


Doesn't "all operations" imply that the provider must implement generic
search operations?  Isn't a large part of the reason for TAPIR Lite the need
to support "databases" that cannot be mapped using the standard RDBMS
mapping and which are just trying to emulate common views?

I would say that these should be supported but that each TDWG content
subgroup needs to define a set of (web service) interfaces that must be
supported by any compliant provider.  If they can handle this set of views,
they may appear as TAPIR providers.

Or did I miss something?

Donald Hobern (dhobern at gbif.org)
Programme Officer for Data Access and Database Interoperability 
Global Biodiversity Information Facility Secretariat 
Universitetsparken 15, DK-2100 Copenhagen, Denmark
Tel: +45-35321483   Mobile: +45-28751483   Fax: +45-35321480

-----Original Message-----
From: tdwg-tapir-bounces at lists.tdwg.org
[mailto:tdwg-tapir-bounces at lists.tdwg.org] On Behalf Of "Döring, Markus"
Sent: 17 November 2005 16:25
To: tdwg-tapir at lists.tdwg.org
Subject: [tdwg-tapir] ideas & TapirLite

talking to Anton today we were wondering if it makes sense to allow a tapir
client to embed its own request-id into the tapir headers for later
identification of asynchronous and distributed messages. Currently we would
need to identify a message by its sendtime (vague) and source.

Does this make sense? Does anyone know how other people deal with this


The other thoughts were about TapirLite.
We both think its a very bad idea to push all responsibility to the client
by allowing any TAPIR service to be very minimalistic. If a client should be
able to contact services that have different operators, operations and
concepts, then I dont think we will get anything interoperable.

I still prefer that these things must exist in the most basic TAPIR service.
Otherwise we should call it different - maybe even TAPIR Lite as a valid
- all operations
- all logical operators
- the main COPs (<=> like)

Cconcepts and response models can be optional without much problems I think.
What do you think? should we sacrifice all this to have few clients but many

BTW, I think we didnt specify anywhere in capabilities if GET or XML
Messaging is supported. So the idea is to always have both for all services,


tdwg-tapir mailing list
tdwg-tapir at lists.tdwg.org

More information about the tdwg-tag mailing list