XSL more than stylesheet

Subject: XSL more than stylesheet
From: "Didier PH Martin" <martind@xxxxxxxxxxxxx>
Date: Mon, 8 Feb 1999 17:24:03 -0500

This time I looked at XSL or at an improved DSSSL more as a transformation
language than to simply a reduced role as a style sheet language.

I went, as usual to OASIS to look at what's new and saw that more and more
announcements are made about new declarative languages based on XML. Some
are simply knowledge bases serialized for exchange, others are more like
imperative languages.

OK now let's bring together two concepts:
a) Domain specific languages
b) XML documents

Because XML is in fact a standardized syntax (I mean here syntax
construction rules) and do not touch semantics, XML could be a good
candidate for domain specific languages and this is a trend that we see
evolving each days.

This means that XML will induce a plethora of interpreters that will "know
what to" do with a declarative program or XML document. There will be also a
need for transformation tools not only from XML to formatting object but
also from XML to imperative instructions and XML to declarative

As a good example of a declarative program (document would be more
appropriate but a paradigm shift is not easy :-), is a CDF document. A CDF
interpreter could be, in fact, a software installation program. You do not
say in the CDF document what to do, you just specify what is contained in
the package. The interpreter figure what to do.

Actually, within the Mozilla development process, a newborn: XUL is an
application specification document. You simply state the application parts
and the interpreter figure out what to do with it and the result is an
application. Idem for BML (IBM stuff), you specify a Bean whole-part
compound and the interpreter figure what to do with it: an application
(especially when BML will have the capability to include scripts or event

Of course, this plethora of DSLs (Domain Specific Languages) will have their
associated interpreters and wont have necessarily the same vocabulary. In
fact, as we already see, XML development do not force everything to be in
the same melting pot but, a highly diverse universe is emerging with several
vocabularies emerging for a same domain. Thus, these vocabularies could be
semantically close enough to be translated from one to the other. This means
that XSL or any other transformation language could be used to transform
from one DSL to an other one as long as both are for the same domain. Thus,
a DSL based document that could be interpreted with a particular interpreter
could be also interpreted on an other one after being transformed by a
transformation language.

Let's say for example that "XUL" is used for Mozilla and that "Ghostbusters"
is used by an other user agent or interpreter (movies fans will recognize
why these two names fits together). XSL could be used to translate from
Ghostbusters to XUL and vise versa. Then a XUL compliant interpreter could
use a Ghostbusters program (XML document based DSL) and vise versa. This
implies that a transformation language could be at the heart of
inter-operability and this gives also more weight to consider the
transformation part of XSL as more than to be simply in the style sheet
category. If we forget, for a moment all political factors, we should also
keep in mind that transformation languages play major role with DSL
interoperability. We do not have this problem yet in our daily lives, but
more and more as we will move from imperative to declarative languages,
transformation languages will become centerpiece to portability or
adaptation to diversity of interpreters.

For more info on DSL you can read some proceedings from a conference on the

For major manufacturers, a certain level of control won't be on the
underlying document syntax (XML) but more on the voabulary and interpreters
that "knows waht to do" with these vocabularies. Of course, we cannot expect
that they would unify under a single vocabulary (are we all talking the same
language on earth?). So expect that the next level of control for these
manufacturers will be on interpreters and vocabularies. Transformations
languages are clients path to freedom of choice.

Didier PH Martin

 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list

Current Thread