Re: moving along on rules language

[Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>]

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.