[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|