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