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