This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: XSLT 1.1 comments
- To: xsl-list at lists dot mulberrytech dot com
- Subject: Re: [xsl] XSLT 1.1 comments
- From: Uche Ogbuji <uche dot ogbuji at fourthought dot com>
- Date: Mon, 12 Feb 2001 17:56:56 -0700
- Reply-To: xsl-list at lists dot mulberrytech dot com
> | and alternatively:
> |
> | -> if two conforming XSLT 1.1 processor implementations both
> | have elected to implement the C++ language for extension
> | functions, then developers can expect that ...
> | Really, what can we expect in this case?
>
> At a minimum, they can expect exactly what they can
> expect in XSLT 1.0, that is, nothing.
>
> Doing better than that, XSLT 1.1 provides an extensible
> <xsl:script> mechanism for vendors to cooperate to agree
> on a common C++ language binding, with a common QName
> that describes the binding and which can be used in
> the <xsl:script language="QName"> construct.
XSLT 1.0 already provided this cafility: with extension functions and
elements. If people need to band together to standardize exceptions, they can
do so without xsl:script. I still haven't heard from you why this isn't so.
> If the vendors do *not* want to cooperate to come up with
> a C++ specific binding that they share, then they are
> in the same situation as with XSLT 1.0.
>
> Net net, XSLT 1.1 neither promotes nor hinders this from happening,
> but it provides a new mechanism to make it possible, should it
> be the will of the web community.
My point is that I see no technical advantages that XSLT 1.1 has added.
Everything it provides for could be done at proper layers using XSLT 1.0.
However, I do see 2 big non-technical disadvantages.
1. It encourages people to write non-interoperable stylesheets (by
introducingxsl:script)
2. It gives a political boost to implementors of Java-based XSLT
implementations (by writing language bindings into the language and allowing
Java as a first-class extension language specification)
What do the Java folks gain by making this clearly controversial addition? If
they need a conveneient URI for their extension namespaces, I'm sure something
can be easily worked out.
--
Uche Ogbuji Principal Consultant
uche.ogbuji@fourthought.com +1 303 583 9900 x 101
Fourthought, Inc. http://Fourthought.com
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list