[tdwg-tapir] TapirLite
Renato De Giovanni
renato at cria.org.br
Tue Nov 22 13:58:33 CET 2005
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
More information about the tdwg-tag
mailing list