Alex Rousskov wrote:
Possibly the most significant reason for using XML, though, is that
it avoids the "Bikeshed problem"
(http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/misc.html#BIKESHED-PAINTING).
Working groups can get terribly tied up in grammar and syntax;
everyone has their own opinion on their favorite format for
comments, for example.
"Fortunately", OPES WG group does not have enough active participants
for the above to become a problem :-/.
Well, then it's even more dangerous - with only so few active
participants, we cannot afford to be distracted by disucssions on
grammar/syntax at all - we should leverage whatever we can.
If we decide to move forward with "P", I would assume that its current
grammar/syntax is accepted as is, and that we won't get distracted by
discussions about style preferences.
You did not mention any performance considerations. I guess they were
not very important becuase you just needed to support an execution of
a static set of alternatives, with each alternative being cheap to
evaluate. In OPES, evaluation can be expensive (e.g., is this HTTP
request going to be a cache hit or miss?) and non-trivial (hit and
request headers contain FooBar but previous service failed). Thus, we
need to optimize and reuse code.
I do *not* believe that the OPES rules language needs to be designed
for performance, simply because I don't assume that OPES processors
will use this language as internal representation for rules evaluation
anyway.
An OPES processor will receive a rules description in the format to be
specified, and then (in my view) will translate it into an internal
(proprietary) and highly efficient data representation - something
tree based comes to mind.
-Markus