Subject: RE: moving along on rules language

From: "Martin Stecher" <[email-masked]>
Date: Wed, 10 Sep 2003 12:24:39 +0200

Hi,

back from holiday I just read draft-rousskov-opes-rules-00 quickly.

In a first reaction, it makes a lot of sense to me and I find it easier to understand and more powerful than IRML.

Though I have a little problem with the example in Figure 10:
  "toDialect" is a term that is very specific for the selected service.
  Does this example assume that "toDialect" is a supported term of standard P or how could a service dynamically add new identifiers and functions calls?

While I can follow Alex comments about IRML and like P better than IRML in the moment, I admit that I did not deal a lot with the rule language requirements all the time, so I may oversea important aspects.

I would very much appreciate if an IRML advocate (Andre?!?) could comment on Alex draft and list problems and aspects that IRML solves better. Such as Alex did before with IRML.

Regards
Martin

> -----Original Message-----
> From: Alex Rousskov [mailto:[email-masked]]
> Sent: Tuesday, September 02, 2003 6:58 PM
> To: OPES WG
> Subject: Re: moving along on rules language
> 
> 
> 
> 
> On Tue, 2 Sep 2003, Markus Hofmann wrote:
> 
> > Alex - I'd suggest you publish this as individual ID right away
> > rather than just having a URL as reference. Would give us all a
> > formal reference for the document.
> 
> Submitted with minor polishing touches.
> 
> Alex.
> 
> ------------------------------------------------------------
> This mail has been scanned by debian3-smtp
> (WebWasher 4.4.1 fcs Build 580)
> ------------------------------------------------------------
>

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 10 Sep 2003 06:46:11 -0600 (MDT)

On Wed, 10 Sep 2003, Martin Stecher wrote:

>   "toDialect" is a term that is very specific for the selected
>   service. Does this example assume that "toDialect" is a supported
>   term of standard P or how could a service dynamically add new
>   identifiers and functions calls?

You have asked a very important question. P "as is" supports only a
few "terms" or objects methods -- those defined in Core and Services
modules. Everything else is provided by other modules that are,
essentially, extensions. When P interpreter finds an expression like
<object-of-some-other-module>.<method-name>() it passes the name of
the method to that other module/object to handle. P Core does not know
a priory whether the other object supports that method, but there is
an interface that allows modules to report unsupported errors back to
Core.

The above scheme allows P modules like Http or Smtp to evolve without
affecting P Core. I believe it can be implemented efficiently.

The same trick can probably be applied to services. Any service will
be implemented as an internal program or some kind of callout service
(via OCP, SOAP, or whatever). For OCP, we will document how to map
service.method-name(params) call to something that OCP callout service
can understand. This trick will allow services to evolve without
affecting P Core. If we find it is too much overhead/complexity to
support this marshaling, we will restrict services to a few
well-known and general-enough methods.

Hope this clarifies,

Alex.

---

From: Andre Beck <[email-masked]>
Date: Wed, 10 Sep 2003 10:08:43 -0400

Hi,

I also came back from vacation this week and just had a quick look at P. 
I still don't believe that the problem we are trying to solve calls for 
a (albeit limited) programming language like P. 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. 
What I like about an XML-based language like IRML is that by design it 
limits the complexity of rule modules. 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. 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.

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. 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.

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. I guess what is needed at this time is for more people 
on the list to speak up and voice their opinion on the two rule language 
proposals.

-Andre

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 10 Sep 2003 11:00:36 -0400

Andre Beck wrote:

> [...] I guess what is needed at this time is for more people 

Folks, this is exactly what we need - we need to get consensus on 
which approach to follow - and we need to get that ASAP. We were 
expected to have an iniial rules WG document in August!

Real conensus can only be achieved if more people take the time and 
look at both approaches and communicate their thoughts. So, please 
start-up your email clients and post your thoughts.

Thanks,
   Markus

---

From: Alex Rousskov <[email-masked]>
Date: Wed, 10 Sep 2003 10:59:46 -0600 (MDT)

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.