On Tue, 24 Jun 2003, Markus Hofmann wrote:
We revived and re-submitted the attached IRML draft in an attempt
to trigger some discussion on how to specify service execution
rules in OPES.
While we're making good progress with the protocol, we're behind
with the rules language. We really need to get going here.
As Andre indicates, re-submission of the individual draft is
intended to trigger some discussions. Please check it out and
provide comments on the list - either to the draft itself or to the
area in general.
I may have few friends left after this message, but I hope that these
comments would do at least some good as well.
My first reaction to the draft is negative. I hope that I missed
something important and that my opinion can be reversed by the
discussion. Below are first high-level comments; no reason to go into
line-by-line specifics if I am wrong about the overall draft
structure/direction.
0) IRLM draft provides insufficient set of general mechanisms for rule
specification yet also documents many HTTP-specific extensions or
bindings. This must be fixed. The draft should either define core
mechanisms and strive to be application agnostic or be
HTTP-specific. In either case, major additions and changes would be
required: more general mechanisms are needed and more/different
HTTP-specific bindings are required. In other words, I am not just
talking about splitting the draft in two.
1) IRLM is closely tied to a very narrow interpretation of the OPES
architecture. The language should focus on a more general (yet
well-scoped) task of expressing a message adaptation rule:
if "condition" then do "action";
The "condition" expression should be powerful enough to express a
mixture of processing points, processor state, application message
properties, and extensions. The draft artificially segregates, for
example, processing points, from message properties, severely
limiting expression power.
[Side note: Fortunately for us, the "action" part is rather
simple -- execute service(s)]
2) IRML attempts to enforce rules authorship. IMO, the Rule
Specification language must focus on specifying the rules, not
trying to specify or enforce who has the right to submit or execute
them. For example, imagine C or Java languages with constructs to
specify/enforce software copyright. I believe that rights
specification and enforcement requires different mechanisms from
rules specification. Moreover, both mechanisms lack key features in
the current draft.
3) I doubt that efficient rule processing would be possible with IRML.
The language provides no mechanisms to reuse groups of rules (e.g.,
procedures or functions) or to reuse computation results (i.e.,
variables). Without such mechanisms, a realistic IRML program will
be slow. It will also be huge and difficult to manage.
4) I question the choice of XML syntax. Rule specification is much
closer to a program than it is to a static tree of configuration
options. I believe that the history of languages used to express
application routing, load balancing, and filtering decisions at
intermediaries proves my point: while the industry has started with
simple maps and tables, the application-level requirements forced
implementors to support much more flexible rule programming. The
choice of XML as IRLM syntax makes it very awkward to express
anything that goes beyond a simple rule. IMO, XML must not be used
as a programming language syntax.
XML justification in the draft is "many publicly available parsers
and editing tools can be used". This is a very weak argument
because (a) getting XML tree parsed is only a minor step towards
interpreting IRML and (b) there are more XML-unaware editing tools
than XML-aware editing tools. The authors claim that "The structure
of the language maps closely to its behavior" which I believe is
true only for the authorship part of the language and only
partially true for the actual rule specification language.
Moreover, the behavior that XML maps to is the wrong one! See items
(1) and (3) above. The last argument (ease of IRML validation) is
also weak because (a) any applicable language syntax would
relatively easy to validate and (b) syntax validation does little
good since most errors are of semantic nature, unrelated to DTD
validity.
If my observations above I correct, I would be surprised to see IRML
supported in practice. It can offer major users a lot less than custom
solutions (future or existing). Again, I would like to be proven wrong
because there is clearly a lot of effort put into the draft, and I am
late with my comments.
HTH,
Alex.