Renato, just quickly. I hadnt enough time to think about your proposal yet. Just wanted to clearify what I meant in my last mail.
The current query templates are referencing models, so they are depending on a model (1 to many relation). I wanted to "liberate" filter templates from any model. So the specification of a filter defining the semantics of GET parameters could be used for both, inventories and searches.
You are right that we would need more for inventories, but its "atomised" enough with our GET definition of an inventory request. The reason why we needed filter templates is ONLY to be able to specify "atomised" get-parameters. Otherwise TAPIR lite services would have had to parse the full serialised filter string and it wold be possible for clients to ask for complex things. If I am correct we only need filter templates because TAPIR Lite wants to avoid complex filter strings. Am I right?
Markus
-----Ursprüngliche Nachricht----- Von: tdwg-tapir-bounces@lists.tdwg.org [mailto:tdwg-tapir-bounces@lists.tdwg.org] Im Auftrag von Renato De Giovanni Gesendet: Dienstag, 22. November 2005 13:59 An: tdwg-tapir@lists.tdwg.org Betreff: Re: [tdwg-tapir] TapirLite
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
_______________________________________________ tdwg-tapir mailing list tdwg-tapir@lists.tdwg.org http://lists.tdwg.org/mailman/listinfo/tdwg-tapir_lists.tdwg.org