[tdwg-tapir] Updates and plans

Renato De Giovanni renato at cria.org.br
Fri Oct 10 22:17:26 CEST 2008


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





More information about the tdwg-tag mailing list