Re: [Fwd: Re: CPL and XML]

[Alex Rousskov <rousskov@xxxxxxxxxxxxxxxxxxxxxxx>]

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.

> XML's tree structure maps naturally onto the decision-tree model of
> 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"
> (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.

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