[tdwg-tapir] TapirLite

[Renato De Giovanni]

Hi Markus,

I'm not sure that all client software will need to handle all 
possible types of TAPIR providers. When writing a client for a 
specific network, one could even assume the level of functionality 
available from all providers and rely on the network registry (UDDI, 
manual configuration file, or whatever) to point only to the 
compatible ones.

On the other hand, I do agree that the new "operators" section in the 
capabilities response is more complicated than necessary. I would 
prefer to see "operators" an optional element (TapirLite would simply 
not have it), but then we could make all other elements inside it 
mandatory (except the custom ones). This way we could easily 
distinguish minimalistic implementations, and at the same time get 
rid of weird situations when a provider could offer the "and" 
operator but not the "or", and things like that. In other words, if 
"operators" is present, we could safely assume a lot of things 
without adding much complexity to clients.
--
Renato

On 17 Nov 2005 at 16:25, Döring, Markus wrote:

> 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 subset: - 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 providers?
> 
> 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, right?
> 
> 
> Markus