[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Splitting XSL

---

---

Here is the text I propose. I look forward to comments.

----
A proposal for the creation of a standard transformation language

"XSL does not require result trees to use the formatting vocabulary and
thus can be used for general XML transformations."
    -- Extensible Stylesheet Language (WD-xsl-19981216)

XSL fits the definition of a transformation language. This situation is
very confusing for many people because XSL claims to be a transformation
language and has the features of a transformation language but its
name has the world "style" in it. It is also clearly intended to be a
stylesheet language.

XSL has this dual nature because of the organization of its specification.
The transformation part of the language is separate from the part that
is specific to stylesheet application. They are equally important but
they are separate. In effect XSL describes essentially two languages,
not one. The first is a transformation language and the second is a
formatting object vocabulary that should be implemented by all renderers.

There are many people who have legitimate reasons to use the
transformation part independently of the style part. We expect the
transformation language to become an important enabler of electronic
commerce, electronic data interchange and metadata interchange. We do not
feel that the engines that support this interchange should be considered
incomplete XSL engines. Instead we would like the transformational part
of XSL to be split out into its own specification. We believe that this
would strengthen both the transformational and formatting parts of what
we now call XSL.

The transformation language could be stronger because conformance could
be formally specified and tested in areas unrelated to stylesheet
application. If it is appropriately named then people looking for a
transformation language would more easily be able to find it. This
transformation language could also be included by reference into other
specifications unrelated to style.

XSL would essentially become the application of the transformation
language to input documents where the result is required to conform to
a formatting object vocabulary. The XSL specification would reference the
transformation language specification and define formatting objects. This
part of XSL would also be strengthened by the fact that conformance
testing would be clearer and simpler. These formatting objects could
also be referenced by other specifications (e.g. CSS3) and even used on
their own as a formatting-based word processor interchange language.

Due to the current organization of XSL there are many "XSL
implementations" that have nothing to do with formatting.  Currently there
is nothing the W3C can do to discourage these "half-implementations"
without also discouraging the use of the transformation language as a
basis for electronic commerce and data interchange. Not only has the W3C
not discouraged these half implementations, one of them is by an editor
of the XSL specification and others are by W3C members!

This muddy definition of "XSL implementation" is dangerous.  Even when
the XSL specification is complete, a browser vendor could conceivably
implement only the transformational part of XSL. When challenged, they
could point to these other half-implementations as evidence that this
was a valid choice to make.

If the languages were separate then it would become clear which browsers
truly implemented XSL and which only implemented the transformation
language. In fact, the W3C could use its copyright to prevent XSL from
being applied to implementations that do not support the formatting
objects. We believe that this branding would be a very effective tool
in defending the true purpose of XSL: interoperable stylesheets.

The signatories to this document do not herein propose any change to
the specification-making process. Opinions vary widely on the best way
to create technical specifications. We do all agree that it is the user
community's right to complain when technology creators do not meet their
needs. We invoke that right in the issue of the XSL language.

<Your Name Here>


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

---