Date: Sun, 28 Feb 1999 09:30:12 -0700
From: Paul Prescod <paul@prescod.net>
To: "xsl-list@mulberrytech.com" <xsl-list@mulberrytech.com>,
xml-dev <xml-dev@ic.ac.uk>,
"dssslist@mulberrytech.com" <dssslist@mulberrytech.com>
Subject: W3C-transformation language petition
Please submit your opinion on the following to:
http://www.prescod.net/xsl/petition/
I would like to get a large sample of the XML/SGML-using community. Readers may also redistribute this and repost it where ever they feel it is appropriate.
A proposal for the creation of a W3C-recommended transformation language
XSL does not require result trees to use the formatting vocabulary and thus can be used for general XML transformations.
- [from] the XSL specification
Although it is billed as a stylesheet language, the Extensible Stylesheet Language fits the definition of a transformation language. As described above, XSL can be used for XML to XML transformations. In fact, most XSL implementations only support the transformational feature. This situation is very confusing for many people. Many potential users want to know exactly what XSL really is.
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 specified as a separate entity. 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. Those using XSL for style application could do so in exactly the same manner that they do today. The formatting 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.
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 the name 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.
We do not propose any particular organization of the specification or specifications. Our requirements are functional:
1. It should be possible to implement only the transformation language and have the implementation conform to some W3C named, formally-defined language.
2. It must not be possible to create an implementation of a W3C-defined language called XSL unless the implementation supports formatting objects.
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.
Please submit your opinion to:
http://www.prescod.net/xsl/petition/
Paul Prescod - ISOGEN Consulting Engineer speaking for only himself http://itrc.uwaterloo.ca/~papresco
"The Excursion [Sport Utility Vehicle] is so large that it will come equipped with adjustable pedals to fit smaller drivers and sensor devices that warn the driver when he or she is about to back into a Toyota or some other object." -- Dallas Morning News
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list