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.