Hello Markus,
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.
Yes, I understood that. I just don't know if pre-defined filters are going to be reused so frequently that it would justify to modularize them. Maybe we could wait for Roger to see how the TCS API will look like?
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?
Yes, I also see that, but I think we have different understandings about pre-defined parameterised inventories. I know that you can do anything with the new GET invocation for inventories, and that's the problem because TapirLite would need to say "I support inventory operations", which means it must be able to understand and process inventory requests for _any_ TCS concept that was mapped, and even more, for any combination of TCS concepts, right?
Maybe I'm wrong, but what I understood from Donald is that TCS TapirLite providers want to say "I don't support generic inventory operations, but I do support a pre-defined inventory on this specific TCS concept with this parameterised filter". -- Renato