Hi Javier,
Query templates in particular do remind part of the idea behind WSDL, although WSDL only provides service descriptions at the syntactic level (probably in a more complete and better way than we're doing). However we do have things related to semantics (the "mapping" section).
I agree that it sounds a bit strange to see TAPIR being used only based on query templates (the APIs for TapirLite). But please remember that query templates (originally "views") were proposed in a very specific context, as I better explained in my previous message. We didn't want to reinvent the wheel, we just wanted to provide easy links on top of our services. And to make that happen, we only needed to include the "parameter" element as part of filters. All other view components were present in regular search operations.
On the other hand, I see no strong reasons to avoid TapirLite at this moment. The biggest difference between original Tapir and TapirLite was the dynamic view part, which is removed now. The other differences still don't make me believe that clients will necessarily become ovely complex. As Roger said, having both approaches under the Tapir fold could be beneficial in the long run, although it seems we cannot tell that in advance. But at least both types of service will share a common metadata and capabilities format. And if I'm a taxonomic concepts provider using a full-featured Tapir software, I can be easily plugged in a TapirLite TCS network (but not the other way around).
Regards, -- Renato
On 18 Nov 2005 at 12:41, Javier de la Torre wrote:
Hi all,
Well Markus, for me this looks like a very different approach... and I think it makes sense, but I think this distinctions between services should not be done in TAPIR and in its capabilities. If you take a look at your new proposal for capabilities it looks like a WSDL file where you describe the kind of service that is behind a web service. The kind of clients we will have to develop to access a network like this will have to be quite complex, first taking a look at the capabilities to know how to query a data provider and then query them. What in reality will happen is that portals, clients, will have their own registry where they store the information about the data providers that they want to use and how they can access them. At the end is like a UDDI where you define different tmodels.
Then, why don't we forget about the TAPIRLite idea and we consider that some data providers will not use TAPIR but rather some simple web service tmodels (that we will provide them) to access them. Eventually we could also ask TAPIR implementations to provide a WSDL file where they emulate these tmodels.
If you are a client that needs to get the data from all possible data providers you will probably use these simple web services interfaces. With this you will create your cache and your portal on top of it. If you are a client that wants to send dynamic queries to data providers, or have more interaction with them using inventories and things like that, then you will use TAPIR and probably you will discard non TAPIR compliant data providers.
Javier.