[tdwg-tapir] ideas & TapirLite

[Renato De Giovanni]

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