W3C home > Mailing lists > Public > xsl-editors@w3.org > January to March 2002

Re: Congrats on the latest WD ::: http://www.w3.org/TR/2001/WD-xslt20 -20011220/

From: Jeni Tennison <jeni@jenitennison.com>
Date: Thu, 17 Jan 2002 19:15:17 +0000
Message-ID: <187902255134.20020117191517@jenitennison.com>
To: "'xsl-editors@w3.org'" <xsl-editors@w3.org>
CC: Raja Cherukuri <raja.cherukuri@telera.com>
Raja Cherukuri wrote:
> The latest working draft
> (http://www.w3.org/TR/2001/WD-xslt20-20011220/) keeps alive the
> original intent XSLT spec. by removing <xsl:script> tag.
> Introduction of this into prior working draft set off different
> vendors/implementers trying to provide their own language bindings.

I disagree. Many implementations had their own mechanisms for
pointing to extension function definitions prior to the XSLT 1.1 WD.

Unfortunately, the XSLT 1.1 WD merged two distinct requirements:

  - the definition of a standard mechanism for pointing to the
    implementations of extension functions
  - the definition of language bindings used in the implementations of
    extension functions

I agree wholeheartedly that the definition of language bindings should
be carried out somewhere other than the XSLT 2.0 spec, to avoid some
languages seeming to be 'blessed' while others are not.

However, I don't believe that this should prevent the definition of a
standard declaration for indicating the implementation(s) of an
extension function. While I agree that the tendency to 'bug out' to a
more familiar language to get round the declarative nature of
XPath/XSLT should be discouraged, I view the extensibility of XPath as
one of its strengths, and something that will be greatly hindered by
the lack of an xsl:script element.

To give an example, say that I need an extension function to get a
directory listing, so that I can tell whether a particular document is
available before I use the document() function. I can't write this
my:directory-listing() extension function in XSLT, with xsl:function,
because XPath doesn't give me that kind of access to the system
environment. I could, however, write it in JavaScript or Java.

This function doesn't rely very much on whatever language binding I
use, so the language binding isn't particularly relevant - I can use
the same code for all the processors that support JavaScript, and all
the processors that support Java. Even if the code did require some
standard language binding, it's very feasible that all processor
implementors have agreed on the same language binding for the same
language -- they tend to be fairly cooperative on the whole ;)

But now I'm stuck. I want my stylesheet to work across processors, but
each processor has its own way of doing the association from the
stylesheet to the implementation. I have to use saxon:script for
Saxon, msxsl:script for MSXML, xalan:component/xalan:script for Xalan
and so on, for all the processors that I can. But this makes the
stylesheet a mess, and knowing me I'll miss out some implementation
that actually does support user-defined functions in JavaScript but
for which I didn't know the appropriate element.

When xsl:script was introduced in the XSLT 1.1 WD, it was contentious
on four points, I think:

  - the way that it 'blessed' certain languages
  - the inability to define extension functions in XSLT as a fallback
  - the embedding of scripts within XSLT stylesheets
  - the validity of the requirement itself

Moving language bindings somewhere other than the XSLT spec addresses
the first point. The xsl:function element addresses the second point.

An xsl:script element that pointed to the implementation through an
href attribute (or something), rather than embedding the script within
the stylesheet, would address the third point.

And I personally don't think that the fourth point is a valid
argument, on two grounds. Firstly, even with the advances in XPath
2.0, there are some requirements for extension functions that simply
cannot be written in XSLT - a my:directory-listing() function is a
good example - or are not easily written in XSLT - such as
trigonometric functions. Secondly, the functionality is already here,
in the form of msxsl:script, saxon:script etc., and it's not going to
go away. The only method that we have of making the support 'sensible'
and keep it compliant with the 'original intent of XSLT' is to control
it within the XSLT spec.

I should say that I'm particularly concerned about the lack of
xsl:script in terms of EXSLT: support for multiple processors is such
a mess at the moment that we have to basically have separate
stylesheets for each processor, which completely undermines the point
of EXSLT - to provide portable stylesheets. Defining xsl:script in
XSLT 2.0 will make EXSLT a lot more useful.



Jeni Tennison
Received on Thursday, 17 January 2002 14:15:25 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:44:22 UTC