W3C-transformation language petition

[Paul Prescod]

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.
  - 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

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)