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