Hello Markus,
That change in the "in" operator was only related to the TCS API suggested by Roger. Right now <values> can only contain literals so TapirLite query templates cannot make proper use of it (there's no bridge with HTTP parameters). By using a sequence of "expression" elements it would be possible to do things like:
<in> <values> <parameter name="sp"/> <values> </in>
Where "sp" could be an HTTP parameter with multiple values.
Or:
<in> <values> <parameter name="sp1"/> <parameter name="sp2"/> <values> </in>
Or maybe other combination mixing parameters, concepts and values - all could be valid. It just seems we can easily be more flexible here without complicating implementation. But you're right, it would also be possible to have a choice between a sequence of literals and a single parameter (if that's what you have in mind).
Regards! -- Renato
Great Renato, we really need to get this done very soon, so I
support the 5th of January.
I agree to most of your changes, but want to
discuss this one a little further:
- Change multiCOPType (basis of the <in>
operator) so that <values> can contain a sequence of "expression" elements instead of only literals. This will allow parameters with multiple values (or multiple parameters) to be used by the TCS API.
Why do we need this? You can always submit
multiple values through the same parameter name. Do we need to have an IN with multiple parameter names? can you give an example?
Markus