Hilarie,
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.
I agree.
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 agree again. IRML already supports just that: it lets you specify one
or more OPES services that are to be executed in the specified order.
However, there still has to be a policy that determines how to order
service execution requests from different rule authors.
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).
Would this be a performance optimization for those requests that can be
served from cache? In other words, are you proposing to cache not only
the content but also some aspects of the rule processing results for
that content?
Andre