[tdwg-tapir] TapirLite
Renato De Giovanni
renato at cria.org.br
Mon Nov 21 13:46:08 CET 2005
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
More information about the tdwg-tag
mailing list