Apparently, with a few changes the current TAPIR protocol could accept custom operators that could be used by filters. At the moment, there's clearly one additional category of operators that could add a lot of value to TAPIR services: spatial operators. But in the future maybe other operators could also be useful. The following changes introduce a new type of operator represented by "XOP" (in the absence of a better name) which could mean extensible operator, or custom operator:
<-- new
So the extensible operator is simply an abstract element that could be "implemented" by concrete operators in any external schema:
LOP types should be changed to accept the new operator:
<-- new
...
<-- new
The following schema tries to define spatial operators based on the same ones available from the OGC Filter Encoding Specification, mainly replacing the OGC property elements by TAPIR concepts. Although being a "redefinition" of the same operators, the idea is to be as similar as possible in order to ease translations between messages and maybe allow code reusability in case some wrapper decides to implement both the WFS and TAPIR protocols.
One advantage in this case is that the "heavy" GML is only referenced by a protocol extension, and not the protocol itself.
But services that understand custom operators should obviously advertise that in their capabilities responses, so the last part of the changes is a new section under the filterCapabilities element as suggested below:
<---- new section
So a wrapper accepting those spatial operators would output something like this:
...