[tdwg-tapir] TapirLite

[Renato De Giovanni]

Hi Markus and everybody,

> So I was thinking why didnt we keep filters and output models entirely
> separate from each other? Why not request a specific output model in a
> search and also request a certain filter-parameter template? This
> could then be reused for inventories where we dont need any output
> model.

Output models and filters are already separated. The outputModelGroup 
is made of structure, indexingElement and mapping. What brings output 
models and filters together are the query templates.

> It would probably also look better in capabilities, if the output
> model is listed separately for searches (see robs portal example) and
> the query templates (maybe better filter templates?) are a distinct
> section in capabilities that can be used in inventories ans searches?

I still don't see how separate pre-defined filters can address pre-
canned inventory operations. If I understood correctly, Donald wants 
to be able to use query templates (output model + parameterised 
filter) associated to inventory operations, not searches. That's 
something we haven't discussed. A query template for an inventory 
operation would look different from the one we have for searches.

I think this goes more in the direction of making all operation 
elements belonging to an abstract substitution group called 
"operation". Requests could be a choice between any concrete 
operation or any template operation. In requests a template operation 
would be specified with an URI that should match one of the available 
templates advertised by the provider (unless the provider understands 
the basic underlying operation to dynamically parse and process the 
template definition).

So operation templates would be defined externally also according to 
the protocol schema. In principle their body could be a search 
template or an inventory template (defined by a search template group 
or an inventory template group - the same structures used to validate 
and specify standard non-template operations).

This really makes me feel that the current "query templates" (which 
I'm now calling operation templates in a more generic sense) should 
not belong to "search" in the capabilities response. So TapirLite 
providers could say that they do not support search and inventory, 
but they do support some "operation templates". On the other hand, 
the same search section under capabilities must provide a clear 
distinction for providers that do support one or more output models 
(like DiGIR2) and providers that support dynamic output models, 
leaving no space for the contradiction pointed in a previous message.

I won't try to sort out more details unless this sounds like a good 
direction for all of us.

After all changes that we recently proposed it seems we still need 
more effort to reach another "point of stability". Past experience 
shows that the process use to work like that, so I think we just need 
enough patience and more discussions. Hopefully the next point of 
stability is not so distant...

Best regards,
--
Renato