RE: [xsl] XSLT 1.1 comments - please stop the bleeding

Subject: RE: [xsl] XSLT 1.1 comments - please stop the bleeding
From: "Evan Lenz" <elenz@xxxxxxxxxxx>
Date: Wed, 14 Feb 2001 13:47:07 -0800
David Carlisle wrote:
>xsl:script, despite its name, isn't about encouraging the use of scripting
languages.

Some things are technically correct but, practically, they are just wrong. I
think this is a perfect example.

I have already heard some people praising XSLT 1.1's inclusion of
xsl:script, because, they say, some problems are just better solved in
procedural code, and this will give them a chance to do so. This is the
first impression that people will get of xsl:script--that now they're able
to include procedural code. This is a wrong impression, because they always
were able to do so if they used an XSLT processor that supports an extension
for this. With xsl:script, they will still need an XSLT processor that
supports an extension for this.

xsl:script is designed to lessen the sting of the non-portability of
extensions. But by making extensions "somewhat more portable", it will
deceive many people into thinking it is now safe to use extension functions
(or thinking that they aren't using an extension function at all). The
reality is that it never was safe and still isn't safe to do so, where
"safe" means that all XSLT processors will support it. That's the essence of
extensions; I understand that. The problem with xsl:script is that it
doesn't look like an extension.

XSLT 1.0 includes a purposeful hole in the model of pure, declarative tree
transformations. This hole coincides with what is non-portable. In
particular, this hole consists of serialization hooks (xsl:output,
disable-output-escaping, etc.) and extensions. I can think of two primary
advantages provided by extensions:

1) XSLT, though in its infancy, is able to solve real-world problems.
2) Implementors and users are able to provide feedback to the W3C about what
extensions work well.

I believe that keeping this hole small is of utmost importance. If true
portability is an ultimate aim, then effort should be put into making this
hole narrower, not wider. xsl:script widens this hole. The distinction
between tactics and strategy comes to mind. xsl:script takes headaches away
now at this stage in the game, but it is counterproductive to the ultimate
strategy of developing a portable, powerful language. (Is that not the
goal?)

XSLT 1.0 even goes out of its way to provide fallback mechanisms for when
particular extensions are not available. This is an effort to stifle the
blow of the non-portability of extensions. It too is a way of making
extensions "somewhat more portable." I understand that xsl:script works
along these same lines. But if portability is a true goal, should we be
giving extensions even *more* concessions? Especially when XSLT 2.0 is
largely about taking away the need for certain extensions?

Please, please, think of the long-term ramifications of xsl:script. I fully
agree and recognize that xsl:script would take away many headaches,
including some of my own. But I also believe this would provide only a
short-term benefit that's not worthy of further widening that hole. The
escape mechanisms are there; people use them. Users and implementors are
learning what works and what doesn't. XSLT is growing and maturing. It takes
time and experience.

In my mind, this debate comes down to one very important question:

    Are XSLT extensions designed to be here forever or not?

In any case, it seems early to assume that they will be here forever and
that we should now make further efforts to make them more practical to use
(xsl:script). With rumors about XPath 2.0 including support for XSDL data
types, etc., it seems awfully early to signal defeat in the battle for
portability. Or was this battle never to be fought?

Francis Norton wrote:
"But XSLT is also good at providing cross-platform portability - indeed one
of it's strengths is that it is more portable than *any* language. This is
something that the XSLT community are, I suspect from feedback in this list,
very keen on...For me, and I suspect for many on xsl-list, what XSLT does is
provide *platform-independent* XML processing."

I wholeheartedly agree with Francis.

I hope that the XSL Working Group will take these apparently widespread
concerns to heart and reevaluate their requirements for XSLT 1.1.

Evan Lenz
XYZFind Corp.



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


Current Thread