On Wed, 10 Sep 2003, Andre Beck wrote:
I still don't believe that the problem we are trying to solve calls
for a (albeit limited) programming language like P.
Let's avoid the undefined term "programming language". IRML is no less
or no more programming language than P, IMO. Just a different
language.
In fact, I think a rule module written in P would be more difficult
to understand and write by people who don't already have experience
with programming languages.
It probably depends on the complexity of a rule module. As a counter
argument (also subjective), I believe a rule module in XML would be
more difficult to understand and write by people who don't already
have experience with XML.
Let's define "programmer" as a person familiar with simple
shell/Basic/Perl/Python/whatever scripts. I would like to assert the
following generalizations:
1a) programmers can handle both IRML and P
1b) programmers would prefer P to IRML
2a) non-programmers would have difficulty handling
both raw P and raw IRML
2b) non-programmers would prefer a GUI (graphical)
way of specifying rules
2c) a human unfamiliar with both scripting and XML,
would learn P at least as fast as she would learn
IRML; P is a higher-level language than IRML
3a) both P and IRML rules can be created using a GUI
3b) P GUI can be identical to IRML GUI or can have
an "advance" mode for those who want more
control or more processing efficiency
4a) most rule writers are programmers
5a) efficient rule execution is important
5b) P allows for important optional optimizations
that IRML-03 does not allow for, given an average
P/IRML interpreter
What I like about an XML-based language like IRML is that by design
it limits the complexity of rule modules.
Agreed as long as "complexity" is viewed as a trade-off rather than a
pure negative characteristic. P allows expressing something that IRML
cannot express. That additional functionality may be useful is some
scenarios. The question is whether there is sufficient number of such
scenarios. This is the question this WG would have to answer.
Another point of view would be a "so what?" question. In other words,
does it hurt to have support for more complex expressions? Do we
expect the interpreter to become much more difficult to write or
slower to run than an IRML interpreter? I do not. Any other good
reasons optional complexity is bad?
IRML rule modules can be represented as well es edited graphically
(using a generic XML editor) in a tree where nodes represent rule
conditions and leaves resulting actions. I think such a
representation would be more intuitive and easier to understand than
a piece of P code.
I disagree that a generic XML editor would help non-programmers much.
Trees, leaves, conditions are foreign terms to them. Is GUI helpful
to non-programmers? Yes! Is a generic XML editor helpful to
non-programmers? Not really.
A nice GUI can be developed for both IRML and P.
Also, when editing IRML rules generic XML editors can provide rule
authors with immediate feedback if rule modules violate the IRML DTD
or XML syntax. I don't think this can be easily done with P.
There are generic editors that support syntax highlighting for nearly
arbitrary programming languages. For a non-programmer, those would be
as (if not more) useful than XML DTD validators.
Also, the value of edit-time syntax checking is marginal, IMO. It
would take just a few seconds to verify written syntax using a
stand-alone P interpreter.
Finally, P syntax is so simple/limited that I doubt a reasonable
person would have hard time using it after the first few hours of
learning.
I also don't agree with all of the design goals that Alex lists in
the introction to P. For example, I don't see a need for the rule
language to be so compact and efficient that it can be interpreted
on the fly. I cannot imagine that an ISP would let an OPES system
process arbitrary rules in real time as it receives them from data
providers/consumers.
ISP will not. A surrogate or CDN intermediary will. Surrogates and CDN
nodes have close relationships with origin servers where anything
coming from the servers is assumed to be valid/authorized so there is
no security concern. The performance issue remains but it is a
flexibility versus speed trade-off that does not have a
one-size-fits-all resolution.
In fact, it is possible that OPES nodes will be more common in closely
controlled environments like server acceleration or CDNs than at ISPs.
I think there will have to be an offline validation and optimization
step. That way the OPES system can rewrite or throw out inefficient
or malicious rule modules that would slow down the OPES system
excessively or unnecessarily otherwise.
Yes, and that is possible with both P and IRML, of course.
That having said, I believe that there is still a lot of potential
to further improve IRML if the WG decides to pursue an XML-based
rule language. For example, CPL (which solves a very similar problem
in the IP tel. space and is also XML-based) has a mechanism that
allows CPL script authors to easily re-use parts of a CPL script
through a reference to it. I would be willing to work on a new IRML
draft version to incorporate such a mechanism as well as address
some of Alex' comments on IRML.
If things like that are done to IRML (and they certainly can be!), you
would eventually get two equally complex/powerful languages, but you
would be constantly fighting XML boundaries in IRML because what you
will be doing will be less and less similar to describing static
hierarchical data (what XML is designed for).
XML may be appropriate for IRML-03. However, I would think that if
rules language has code and value reuse, it is a bad idea to use XML.
As you have noted, we need feedback from other people on the list.
Thank you,
Alex.