Re: [tdwg-tapir] ideas & TapirLite
I would like to get into the lite idea a bit more in detail. Lets start with the list of expected "levels" of tapir compliant services: 1- a full TAPIR service incl an experimental dynamic custom output model 2- a full TAPIR service restricted to certain output models identfied via a list of URLs pointing to the output model definition documents 3- a TAPIR Lite that only wants to accept certain parameters for fixed queries. The main idea as I can see is to have a limited list (maybe only 1?) of query templates here (reminder: QTs are filters & a URL reference to an output model) that define the accepted parameters. I assume this service also only works via http GET and not through xml messaging. The difference between level 1 & 2 is quite small (not necessarily for implementations though). The list of accepted output models simply go into the capabilities of a provider and a client can easily identfy if it is able to communicate with a datasource service. A level 3 TAPIR lite service is quite different from the others. Essentially its a regular GET based webservice that can be described by a WSDL, cause no serialised filter is allowed and the response model is fixed. If we really want to define these kind of simple services with the same protocol schema, what should be its "capabilities"? - only http GET invocation, no xml messaging - the TAPIR envelope should be supported for responses - ping, metadata, capabilites should work - no inventory operation - no (complex) filters or variables, only parameters If only parameters are accepted, then this is not a real search. In the old protocol this was a distinct "view" operation. What we want here is exactly this again. A service only available via http get and parameters. A list of accepted query templates would be enough and no operators, variables and alike need to be supported. The current definition of capabilities does only allow to specify http-GET only services or the accepted list of query templates by the way! A new adhoc idea: what about defining these 3 levels and allowing no other intermediate compliance? Then we can reduce the capabilities a lot, a lot of burden would be removed from clients and we would get more interoperability? Just a quick thought when looking at the above. We could make it as simple as this: <FullService accept_custom_models="false"> <supportedModels> <model location="URI" namespace=""> ... </supportedModels> <concepts> <concept id="..." /> ... </concepts> </FullService> or <LiteService> <supportedQueryTemplates> <template location="URI"> <parameter name="" /> ... </template> ... </supportedQueryTemplates> </LiteService> What do you think? I am really a bit afraid of ending up with different services that implement only bits of the specification. We are about to move all burden towards the clients which for my feeling should be easy to create as a researcher with just simple programming knowledge. Sorry to raise this issue again and especially for this drastic new suggestion. It came up while writing this mail, so dont take it for a well thought idea. I just want to think a bit more about the problems involved in having variable and mutating tapir services. Markus -----Ursprüngliche Nachricht----- Von: Roger Hyam [mailto:roger@tdwg.org] Gesendet: Freitag, 18. November 2005 10:32 An: Donald Hobern Cc: Döring, Markus; tdwg-tapir@lists.tdwg.org Betreff: Re: [tdwg-tapir] ideas & TapirLite As TapirLite champion I do have a problem with having to implement all the operators. I just want to be pretty and dumb! I don't have a problem with the concept of a named subset protocol i.e. Tapir (the real thing) and TapirLite (the not so bright second cousin). Are there some use cases somewhere listing what Tapir clients are expected to call or some statistical break down of what kinds of queries are run against existing BioCASE and DiGIR providers? Roger Donald Hobern wrote:
Markus,
Doesn't "all operations" imply that the provider must implement generic search operations? Isn't a large part of the reason for TAPIR Lite the need to support "databases" that cannot be mapped using the standard RDBMS mapping and which are just trying to emulate common views?
I would say that these should be supported but that each TDWG content subgroup needs to define a set of (web service) interfaces that must be supported by any compliant provider. If they can handle this set of views, they may appear as TAPIR providers.
Or did I miss something?
Donald
--------------------------------------------------------------- Donald Hobern (dhobern@gbif.org) Programme Officer for Data Access and Database Interoperability Global Biodiversity Information Facility Secretariat Universitetsparken 15, DK-2100 Copenhagen, Denmark Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480 ---------------------------------------------------------------
-----Original Message----- From: tdwg-tapir-bounces@lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] On Behalf Of "Döring, Markus" Sent: 17 November 2005 16:25 To: tdwg-tapir@lists.tdwg.org Subject: [tdwg-tapir] ideas & TapirLite
Hi, talking to Anton today we were wondering if it makes sense to allow a tapir client to embed its own request-id into the tapir headers for later identification of asynchronous and distributed messages. Currently we would need to identify a message by its sendtime (vague) and source.
Does this make sense? Does anyone know how other people deal with this problem?
-----------
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
_______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
_______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
-- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger@tdwg.org +44 1578 722782 -------------------------------------
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. On 18/11/2005, at 11:33, Döring, Markus wrote:
I would like to get into the lite idea a bit more in detail. Lets start with the list of expected "levels" of tapir compliant services:
1- a full TAPIR service incl an experimental dynamic custom output model
2- a full TAPIR service restricted to certain output models identfied via a list of URLs pointing to the output model definition documents
3- a TAPIR Lite that only wants to accept certain parameters for fixed queries. The main idea as I can see is to have a limited list (maybe only 1?) of query templates here (reminder: QTs are filters & a URL reference to an output model) that define the accepted parameters. I assume this service also only works via http GET and not through xml messaging.
The difference between level 1 & 2 is quite small (not necessarily for implementations though). The list of accepted output models simply go into the capabilities of a provider and a client can easily identfy if it is able to communicate with a datasource service.
A level 3 TAPIR lite service is quite different from the others. Essentially its a regular GET based webservice that can be described by a WSDL, cause no serialised filter is allowed and the response model is fixed. If we really want to define these kind of simple services with the same protocol schema, what should be its "capabilities"? - only http GET invocation, no xml messaging - the TAPIR envelope should be supported for responses - ping, metadata, capabilites should work - no inventory operation - no (complex) filters or variables, only parameters
If only parameters are accepted, then this is not a real search. In the old protocol this was a distinct "view" operation. What we want here is exactly this again. A service only available via http get and parameters. A list of accepted query templates would be enough and no operators, variables and alike need to be supported.
The current definition of capabilities does only allow to specify http-GET only services or the accepted list of query templates by the way!
A new adhoc idea: what about defining these 3 levels and allowing no other intermediate compliance? Then we can reduce the capabilities a lot, a lot of burden would be removed from clients and we would get more interoperability? Just a quick thought when looking at the above.
We could make it as simple as this:
<FullService accept_custom_models="false"> <supportedModels> <model location="URI" namespace=""> ... </supportedModels> <concepts> <concept id="..." /> ... </concepts> </FullService>
or
<LiteService> <supportedQueryTemplates> <template location="URI"> <parameter name="" /> ... </template> ... </supportedQueryTemplates> </LiteService>
What do you think? I am really a bit afraid of ending up with different services that implement only bits of the specification. We are about to move all burden towards the clients which for my feeling should be easy to create as a researcher with just simple programming knowledge.
Sorry to raise this issue again and especially for this drastic new suggestion. It came up while writing this mail, so dont take it for a well thought idea. I just want to think a bit more about the problems involved in having variable and mutating tapir services.
Markus
-----Ursprüngliche Nachricht----- Von: Roger Hyam [mailto:roger@tdwg.org] Gesendet: Freitag, 18. November 2005 10:32 An: Donald Hobern Cc: Döring, Markus; tdwg-tapir@lists.tdwg.org Betreff: Re: [tdwg-tapir] ideas & TapirLite
As TapirLite champion I do have a problem with having to implement all the operators. I just want to be pretty and dumb! I don't have a problem with the concept of a named subset protocol i.e. Tapir (the real thing) and TapirLite (the not so bright second cousin).
Are there some use cases somewhere listing what Tapir clients are expected to call or some statistical break down of what kinds of queries are run against existing BioCASE and DiGIR providers?
Roger
Donald Hobern wrote:
Markus,
Doesn't "all operations" imply that the provider must implement generic search operations? Isn't a large part of the reason for TAPIR Lite the need to support "databases" that cannot be mapped using the standard RDBMS mapping and which are just trying to emulate common views?
I would say that these should be supported but that each TDWG content subgroup needs to define a set of (web service) interfaces that must be supported by any compliant provider. If they can handle this set of views, they may appear as TAPIR providers.
Or did I miss something?
Donald
--------------------------------------------------------------- Donald Hobern (dhobern@gbif.org) Programme Officer for Data Access and Database Interoperability Global Biodiversity Information Facility Secretariat Universitetsparken 15, DK-2100 Copenhagen, Denmark Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480 ---------------------------------------------------------------
-----Original Message----- From: tdwg-tapir-bounces@lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] On Behalf Of "Döring, Markus" Sent: 17 November 2005 16:25 To: tdwg-tapir@lists.tdwg.org Subject: [tdwg-tapir] ideas & TapirLite
Hi, talking to Anton today we were wondering if it makes sense to allow a tapir client to embed its own request-id into the tapir headers for later identification of asynchronous and distributed messages. Currently we would need to identify a message by its sendtime (vague) and source.
Does this make sense? Does anyone know how other people deal with this problem?
-----------
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
_______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
_______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
--
------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger@tdwg.org +44 1578 722782 -------------------------------------
_______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
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.
Hi Markus, The original motivations behind TapirLite was a reaction to the custom response model (which seemed very difficult to implement) and the perceived need for a simple web service like system that could be implemented in a simple way on top of complex 'legacy' systems. The fact that the custom response models are now formally on more of an experimental footing has removed 50% of the motivation but the simple service motivation remains. You are correct in that TapirLite isn't really Tapir at all. It IS just a GET based web service. The kind of thing that full Tapir implementations would have no problem in imitating. Currently (well some of the time) I am trying to figure out a simple API for taxonomic data source that will enable people like Donald to crawl them in something of a meaningful way. I can't assume that data providers will be happy to install (or write) a full Tapir implementation (what if you are in a .Net only environment etc). They have their own agendas and the simpler the system they have to put in place the more likely they are to do it. My hope was to keep them within the Tapir fold. So options are: 1. Define the API in terms of simple http calls. Data providers can either write their own script or they can get a full Tapir provider to imitate the taxonomic API. Advantage is it might actually be quick and easy both to define and implement. Disadvantage is it doesn't integrate with other Tapir providers in the long run - no metadata or capabilities responses. 2. Define the API in terms of templated Tapir calls and insure that any script that is written makes the data provider look like a very limited Tapir provider (the TapirLite approach). Advantage is that it provides consistent metadata and other calls in line with other Tapir providers. Disadvantage is that it actually adds complexity to the Tapir protocol by having too many things optional and adds complexity to the custom scripts. 3. Use another technology altogether such as SOAP or XML-RPC to expose the API. Advantage is that organisation and individuals involved are familiar with the technologies, easier to hire and outsource etc (VisualStudio doesn't yet provide a Tapir integration wizard!). Disadvantage is that it doesn't integrate with Tapir. As I write this all three approaches look equally attractive so I am not advocating anything just rolling ideas around. I'd be grateful for any thoughts that help clarify this. If it would mean getting Tapir to version 1 quicker if option 2 above was dropped then it might be a good strategy. I assume Tapir's primary function is to unite DiGIR and BioCASE and the notion of TapirLite probably should not get in the way of this. Roger Döring, Markus wrote:
I would like to get into the lite idea a bit more in detail. Lets start with the list of expected "levels" of tapir compliant services:
1- a full TAPIR service incl an experimental dynamic custom output model
2- a full TAPIR service restricted to certain output models identfied via a list of URLs pointing to the output model definition documents
3- a TAPIR Lite that only wants to accept certain parameters for fixed queries. The main idea as I can see is to have a limited list (maybe only 1?) of query templates here (reminder: QTs are filters & a URL reference to an output model) that define the accepted parameters. I assume this service also only works via http GET and not through xml messaging.
The difference between level 1 & 2 is quite small (not necessarily for implementations though). The list of accepted output models simply go into the capabilities of a provider and a client can easily identfy if it is able to communicate with a datasource service.
A level 3 TAPIR lite service is quite different from the others. Essentially its a regular GET based webservice that can be described by a WSDL, cause no serialised filter is allowed and the response model is fixed. If we really want to define these kind of simple services with the same protocol schema, what should be its "capabilities"? - only http GET invocation, no xml messaging - the TAPIR envelope should be supported for responses - ping, metadata, capabilites should work - no inventory operation - no (complex) filters or variables, only parameters
If only parameters are accepted, then this is not a real search. In the old protocol this was a distinct "view" operation. What we want here is exactly this again. A service only available via http get and parameters. A list of accepted query templates would be enough and no operators, variables and alike need to be supported.
The current definition of capabilities does only allow to specify http-GET only services or the accepted list of query templates by the way!
A new adhoc idea: what about defining these 3 levels and allowing no other intermediate compliance? Then we can reduce the capabilities a lot, a lot of burden would be removed from clients and we would get more interoperability? Just a quick thought when looking at the above.
We could make it as simple as this:
<FullService accept_custom_models="false"> <supportedModels> <model location="URI" namespace=""> ... </supportedModels> <concepts> <concept id="..." /> ... </concepts> </FullService>
or
<LiteService> <supportedQueryTemplates> <template location="URI"> <parameter name="" /> ... </template> ... </supportedQueryTemplates> </LiteService>
What do you think? I am really a bit afraid of ending up with different services that implement only bits of the specification. We are about to move all burden towards the clients which for my feeling should be easy to create as a researcher with just simple programming knowledge.
Sorry to raise this issue again and especially for this drastic new suggestion. It came up while writing this mail, so dont take it for a well thought idea. I just want to think a bit more about the problems involved in having variable and mutating tapir services.
Markus
-----Ursprüngliche Nachricht----- Von: Roger Hyam [mailto:roger@tdwg.org] Gesendet: Freitag, 18. November 2005 10:32 An: Donald Hobern Cc: Döring, Markus; tdwg-tapir@lists.tdwg.org Betreff: Re: [tdwg-tapir] ideas & TapirLite
As TapirLite champion I do have a problem with having to implement all the operators. I just want to be pretty and dumb! I don't have a problem with the concept of a named subset protocol i.e. Tapir (the real thing) and TapirLite (the not so bright second cousin).
Are there some use cases somewhere listing what Tapir clients are expected to call or some statistical break down of what kinds of queries are run against existing BioCASE and DiGIR providers?
Roger
Donald Hobern wrote:
Markus,
Doesn't "all operations" imply that the provider must implement generic search operations? Isn't a large part of the reason for TAPIR Lite the need to support "databases" that cannot be mapped using the standard RDBMS mapping and which are just trying to emulate common views?
I would say that these should be supported but that each TDWG content subgroup needs to define a set of (web service) interfaces that must be supported by any compliant provider. If they can handle this set of views, they may appear as TAPIR providers.
Or did I miss something?
Donald
--------------------------------------------------------------- Donald Hobern (dhobern@gbif.org) Programme Officer for Data Access and Database Interoperability Global Biodiversity Information Facility Secretariat Universitetsparken 15, DK-2100 Copenhagen, Denmark Tel: +45-35321483 Mobile: +45-28751483 Fax: +45-35321480 ---------------------------------------------------------------
-----Original Message----- From: tdwg-tapir-bounces@lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] On Behalf Of "Döring, Markus" Sent: 17 November 2005 16:25 To: tdwg-tapir@lists.tdwg.org Subject: [tdwg-tapir] ideas & TapirLite
Hi, talking to Anton today we were wondering if it makes sense to allow a tapir client to embed its own request-id into the tapir headers for later identification of asynchronous and distributed messages. Currently we would need to identify a message by its sendtime (vague) and source.
Does this make sense? Does anyone know how other people deal with this problem?
-----------
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
_______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
_______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org
-- ------------------------------------- Roger Hyam Technical Architect Taxonomic Databases Working Group ------------------------------------- http://www.tdwg.org roger@tdwg.org +44 1578 722782 -------------------------------------
Hi again... (sorry about not being able to respond promptly when multitasking...) Markus, you're right that there are more things that are missing in the current protocol in order to address TapirLite as it was originally conceived. The "view" operation was only available through GET parameters without any XML in requests. And it didn't accept custom filters or partial structures. It was mainly a means to allow easy creation of links giving access to useful XML views on top of our services (it would be a sad contradiction to have such powerful services without being able to easily create links to data). In other words, the idea was just to make it possible for "first class objects" to reveal themselves from existing data provider services. Views were not even intended to be used as the basis of interoperability in our networks (remember that they used to be referenced by local aliases!). The idea of TapirLite changed the original intention of views by bringing them to the interoperability front and thus requiring URIs as their identifiers - which was a good thing. And it also changed the very Tapir core by dropping the need to support dynamic output models - which is now an optional feature also for other reasons. So if I'm understanding correctly, even if we make "operators" optional, according to the new schema TapirLite would still need to be able to handle XML requests and also the "partial" structure parameter - which was not expected for "views" in the previous protocol version and may not be trivial to implement. Your suggestion of having <FullService> and <LiteService> looks a bit drastic to me, but it also recalls the possibility of bringing back the other operation that we dropped (call it "view" or any other name). As it was previously defined, this operation would not support XML messages in requests, and would not support the parameters "filter" and "partial". In this case, the current capabilities section for "queryTemplates" would need to move under this new (old?) operation, but searches could also make use of them. Another option would be to keep the operations as they are now, include an attribute called "partial" in the "queryTemplates" element (or somewhere else?) to indicate if partial structures are accepted, and on the other hand force TapirLite to also understand XML requests (should not be a big deal in this case, or am I wrong?). Regards, -- Renato On 18 Nov 2005 at 11:33, Döring, Markus wrote:
I would like to get into the lite idea a bit more in detail. Lets start with the list of expected "levels" of tapir compliant services:
1- a full TAPIR service incl an experimental dynamic custom output model
2- a full TAPIR service restricted to certain output models identfied via a list of URLs pointing to the output model definition documents
3- a TAPIR Lite that only wants to accept certain parameters for fixed queries. The main idea as I can see is to have a limited list (maybe only 1?) of query templates here (reminder: QTs are filters & a URL reference to an output model) that define the accepted parameters. I assume this service also only works via http GET and not through xml messaging.
The difference between level 1 & 2 is quite small (not necessarily for implementations though). The list of accepted output models simply go into the capabilities of a provider and a client can easily identfy if it is able to communicate with a datasource service.
A level 3 TAPIR lite service is quite different from the others. Essentially its a regular GET based webservice that can be described by a WSDL, cause no serialised filter is allowed and the response model is fixed. If we really want to define these kind of simple services with the same protocol schema, what should be its "capabilities"? - only http GET invocation, no xml messaging - the TAPIR envelope should be supported for responses - ping, metadata, capabilites should work - no inventory operation - no (complex) filters or variables, only parameters
If only parameters are accepted, then this is not a real search. In the old protocol this was a distinct "view" operation. What we want here is exactly this again. A service only available via http get and parameters. A list of accepted query templates would be enough and no operators, variables and alike need to be supported.
The current definition of capabilities does only allow to specify http-GET only services or the accepted list of query templates by the way!
A new adhoc idea: what about defining these 3 levels and allowing no other intermediate compliance? Then we can reduce the capabilities a lot, a lot of burden would be removed from clients and we would get more interoperability? Just a quick thought when looking at the above.
We could make it as simple as this:
<FullService accept_custom_models="false"> <supportedModels> <model location="URI" namespace=""> ... </supportedModels> <concepts> <concept id="..." /> ... </concepts> </FullService>
or
<LiteService> <supportedQueryTemplates> <template location="URI"> <parameter name="" /> ... </template> ... </supportedQueryTemplates> </LiteService>
What do you think? I am really a bit afraid of ending up with different services that implement only bits of the specification. We are about to move all burden towards the clients which for my feeling should be easy to create as a researcher with just simple programming knowledge.
Sorry to raise this issue again and especially for this drastic new suggestion. It came up while writing this mail, so dont take it for a well thought idea. I just want to think a bit more about the problems involved in having variable and mutating tapir services.
Markus
participants (4)
-
"Döring, Markus" -
Javier de la Torre -
Renato De Giovanni -
Roger Hyam