Subject: [Fwd: Re: CPL and XML]

From: Andre Beck <[email-masked]>
Date: Wed, 10 Sep 2003 16:28:00 -0400

As I mentioned before, the IPTEL WG has specified CPL as a processing
language for IP telephony and I believe that IPTEL had similar
requirements for CPL as we have for the OPES rule language. So I asked
Jonathan Lennox (who co-authored CPL) if he remembered the reasons why
the IPTEL WG decided to base CPL on XML and he kindly provided the 
following response.

-Andre

Subject: Re: CPL and XML
From: Jonathan Lennox <[email-masked]>
To: Andre Beck <[email-masked]>
Date: Wed, 10 Sep 2003 13:44:20 -0400

On Tuesday, September 9 2003, "Andre Beck" wrote to "[email-masked]" saying:

> Hi Jonathan,
> 
> The OPES wg is currently debating whether or not to base the OPES rule 
> specification language on XML. The purpose of the rule language is to 
> let OPES users specify rules that determine which (HTTP) messages 
> require additional processing by one or more OPES services. It seems to 
> me that CPL solves a similar problem for IP tel. So I was wondering if 
> we can learn from your experience with CPL. Do you remember why you 
> decided to base CPL on XML? Did you ever consider using other formats 
> for CPL, e.g. a simple programming/configuration language?

I did consider using other languages for CPL -- the two main thoughts were
"something kind of like Tcl" and "something based on sieve".

There were a number of reasons for basing CPL on XML, though.  First of all,
XML's tree structure maps naturally onto the decision-tree model of
telephony services: try this, and if it doesn't work, try that.  While
"programming" languages generally support this, "configuration" languages
usually don't -- they tend to be more in the attribute/value model.  I'm not
sure how significant this is for OPES; I've not followed it very much.

XML has a number of nice features because it's so widely supported.  A
student here at Columbia has done a project to display CPL scripts in an
easy-to-read graphical format, using XSL-T; the same project would have been
rather more complicated, requiring writing new parsers and the like, if a
custom grammar had been used.

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.  Using
an established, flexible language forces the group to concentrate on the
actual hard problems -- *what* information should be encoded by the format,
and what it should mean, rather than *how* it's encoded.

XML also lets you use existing (debugged) parsers, rather than writing your
own, which is very useful.

I hope this is helpful for you!

-- 
Jonathan Lennox
[email-masked]

---

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

On Wed, 10 Sep 2003, Andre Beck wrote:

> As I mentioned before, the IPTEL WG has specified CPL as a
> processing language for IP telephony and I believe that IPTEL had
> similar requirements for CPL as we have for the OPES rule language.
> So I asked Jonathan Lennox (who co-authored CPL) if he remembered
> the reasons why the IPTEL WG decided to base CPL on XML and he
> kindly provided the following response.

Andre,

	It is great that you were able to get a first-hand
explanation. Thank you, Jonathan, for providing a detailed response.
I think your reasons and reasons that you do _not_ mention will help
this WG a lot.

	I will summarize Jonathan's (IPTEL WG) points regarding XML
use for CPL and will try to map that to OPES WG situation. This
mapping is all my subjective opinion, of course.

> telephony services: try this, and if it doesn't work, try that.

In the OPES services world, the focus is on the if-statement condition
and service execution parameters rather than fallback mechanisms.
Fallback mechanism must be supported, of course.

> While "programming" languages generally support this,
> "configuration"  languages usually don't -- they tend to be more in
> the attribute/value model.

Both proposed rules languages support this.

> XML has a number of nice features because it's so widely supported.

As a developer, I was not that impressed with XML "support" 6 month or
so ago, when I last needed it. There are only a few decent libraries.
When you add cost/licensing, language, and size into the mix, you are
often left with pretty much nothing. Fortunately, a simple/limited XML
parser is easy to write.

> A student here at Columbia has done a project to display CPL scripts
> in an easy-to-read graphical format, using XSL-T; the same project
> would have been rather more complicated, requiring writing new
> parsers and the like, if a custom grammar had been used.

IMHO, if P takes 100 man/hours to visialize and IRML takes 1 man/hours
to visualize, they are about the same as far as visialization is
concerned. Note that im most cases there should be no need for a _new_
parser (for visualization) in either case bacause a parser is required
to interpret either language anyway. 1 man/hour is better, of course,
but only marginally if we consider production application of the
technology. I am also not yet convinced that visualization is
important for OPES. Most proxy administrators I know prefer editing
configuration files to using GUIs. Their bosses prefer reading MS Word
files to editing via GUIs.

From another point of view, with parser generators like Spirit, it
takes very little time to parse a BNF. So even if you do work from
scratch, there are tools available to help you.

> Possibly the most significant reason for using XML, though, is that
> it avoids the "Bikeshed problem"
> 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 :-/.

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.

Thanks again,

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Wed, 10 Sep 2003 22:45:19 -0400

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

> 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

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 11 Sep 2003 09:45:31 -0600 (MDT)

On Wed, 10 Sep 2003, Markus Hofmann wrote:

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

That's my expectation. There will be some additions and polishing
actions as the current grammar is not 100% complete, but I really
doubt we will run into Bikeshed problems due to P syntax. We can run
into them due to P/IRML semantics, of course.

> will use this language as internal representation for rules
> evaluation anyway.

Let's use English then :-)

Seriously, compilers and interpreters can do only so much. If we care
about performance and the problem domain is not trivial, we must
include human code writers into the loop. We are not talking Assembly
language here, but some major human-hints would be requried in rule
modules for them to be interpreted efficiently.

This is the same as writing programs in modern programming languages
like C++ or Java -- the languages are high-level, but have enough
knobs to optimize performance where it counts. If compilers were so
smart as you may be implying, we would be writing all programs in
Prolog or a similar declarative language.

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

Yes, but building an efficient bytecode requires programmer hints
(i.e., language support).

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Thu, 11 Sep 2003 14:09:35 -0400

> (i.e., language support).

This is why somthing XML-based might be of interest - it maps 
naturally into a tree-based structure, which IMHO makes a cood base 
for an efficiednt bytecode.

-Markus

PS: Jonathan - sorry for swamping you with OPES stuff, if you want to 
get off the discussion, please say so.

---

From: Alex Rousskov <[email-masked]>
Date: Thu, 11 Sep 2003 13:32:54 -0600 (MDT)

> for an efficiednt bytecode.

True. The question is whether all we want to support has a natural
mapping into a tree-based structure. If yes, XML is OK. If no, XML is
an obstacle. I do not think that all rule modules we need to support
naturally come with a tree-based structure. I disagree that the
problem worth solving is that simple.

Of course, any procedural program can be forced into a tree-based
structure. I do not want to force rule writers to do unnatural things.
Natural expression is the whole point of having a domain-specific
language.

Alex.

---

From: Markus Hofmann <[email-masked]>
Date: Thu, 11 Sep 2003 16:07:45 -0400

Alex Rousskov wrote:

> mapping into a tree-based structure. 

We need input and views from more folks here - specific examples will 
also help.

-Markus