The rules language should not be a programming language - it should be
a constrained language that can be compiled into efficient runtime
dispatches. XML seems like a reasonable way to represent rules,
prior to compilation.
The elements needed are regular expressions based on tokens; the
tokens should encompass not only character strings but also
grammatical elements from the underlying protocol. A BNF definition
of the underlying protocol, for example, should provide the basis
for the OPES rules language to specify header and body constructs.
However, I believe that the constraint of triggering only a single
action is too severe. It is important to be able to specify
sequencing: e.g., action1, then action2.
I am a proponent of an approach that supports detailed parsing of
cached content. In this model, the OPES processor would take the
content-related rule elements and compile them into a single parsing
routine. This code might run on an OPES helper machine. The OPES
processor would then attach the parsed attributes to cached items.
Requests for such items would trigger OPES rules related to requestor
profiles; the rules would determine which OPES services were to be
applied to the cached items (such as, delivering an already modified and
cached item, or applying further customization to such an item, or blocking
the item).
Hilarie