Re: [xsl] XSLT 1.1 comments

Subject: Re: [xsl] XSLT 1.1 comments
From: "Steve Muench" <Steve.Muench@xxxxxxxxxx>
Date: Mon, 12 Feb 2001 17:40:58 -0800
| What was wrong with the extension mechanisms in XSLT 1.0 that couldn't be 
| sorted out with a language binding *outside* the XSLT spec.  This is how DOM, 
| CORBA, etc. handle language-specifics.

The XSL Working Group has done exactly what the DOM and SVG groups
have done. All three provide language bindings as normative appendices
to their specification. Not sure what you mean by DOM's handling it's
language-specifics *outside* the spec. We specifically followed the DOM
and SVG Working Group's lead on this area.

That said, there are C-based implementation of DOM's, but to my
knowledge no *standard* api for C-based implementation of DOM's
so perhaps the fact that the DOM spec includes a Java language binding
an an ECMAScript language binding *has* made it easier for web
developers working in Java and ECMAScript to apply the DOM to
their daily work? That's clearly not *all* web developers but
it is a non-zero sized population that has benefitted.

| What's so special about XSLT that crutches have to be hard-wired 
| in for the Java folks?

Are you essentially saying that you want writing extension functions
in Java or ECMAScript to be equally complicated to providing them
in any language? In effect, if I've understood you correctly, you
are objecting to the existing of "shortcuts" for ecmascript and java?
In the end, we're just saving a few characters. That is, as the 
spec is written now...

   <xsl:script language="java">

is a shortcut for:

   <xsl:script language="someW3CPrefix:java">

which might as well be:

   <xsl:script language="xsl:java">

So whether it is language="java" or language="xsl:java", does this
make a big difference?

| The first problem I see with xsl:script is the human engineering aspect.  XSLT 
| 1.0 had extensions but had the admirable quality that extensions were opaque 
| to XSLT itself.  This encourages people using XSLT to have the XSLT mind-set 
| and learn how to solve problems within the language.

With all due respect, I don't buy this argument. When people haven't been 
able to figure out the "XSLT Way" to do something, they've turned to
built-in extensions like saxon:node-set, ora:node-set, xt:node-set, or
extension elements like <saxon:document>, <ora:document>, or <xt:document>.
In the case of SAXON users, they enjoy a huge variety of built-in extension
functions that Michael Kay has diligently been adding in response to user
feedback. These vendors could have gotten together, agreed on a common
namespace, and agreed to implement some <common:document> and common:node-set()
function. But then user-written extensions cannot enjoy this same portability
since the user writing the extension cannot control the binding between the
XSLT processor and the extension function implementation language.

| I think this 
| healthy layering is a good part of the reason why there has been so much 
| advancement of the state of XSLT practice in just one year: it was quite clear 
| how to layer one's thinking between XSLT and extension.  With xsl:script, the 
| layers are muddies, and I think it will lead people (who, after all often 
| search for expedient over good sense) to jump in with extensions without mind 
| to the inevitable interoperability problems.

If someone wants to do extensions, they have to learn an XSLT-processor
proprietary method for doing so. Many people use <msxsl:script> when they
convert their stylesheets for IE5's original XSL implementation to 
their latest MSXSL3 implementation. I don't see what additional allure the
introduction of <xsl:script> has for developers. It's as if you are saying
that people will use XSLT 1.1 stylesheets as a convenient shell for 
doing ECMAScript programming like this:

   <xsl:stylesheet version="1.1" xmlns:xsl="..." xmlns:my="urn:my">
     <xsl:script language="ecmascript implements-prefix="my">
       function main() {
         // thousands upon thousands of lines of raw DOM programming here
     <xsl:template match="/">
       <xsl:copy select="my:main(/)"/>

If they are hell-bent on doing this, then they probably are
already doing it today with their vendor's proprietary scripting
extensions, so their "souls" are already lost... :-)

| The xsl:script section contains all sorts of horrid prescriptions.

Rather than describing these as horrid prescriptions, I believe
you are below correctly pointing out some places where the
spec (remember, it's a FIRST WORKING DRAFT) needs to be clarified.

| I'll just  run through the gamut
| "The implementation of the extension functions identifies the local names of 
| the functions that is is implementing."
| Python's dynamicism means that these implementing functions can change.  Is it 
| the statically defined or current dynamic function set that is used to map the 
| local names?

As long as your processor implements function-available() correctly, does the
spec have to specifically answer this question? I don't believe it needs to
be concrete about this. If you have a suggested wording that would make
this point more clear, please do forward it to xsl-editors@xxxxxxx 

| BTW, why are the language names other than the Sanctified Three specified as 
| Qnames?

The 'language' attribute on <xsl:script> is designed to work *exactly* like
the 'data-type' attribute on <xsl:sort> and
the 'method' attribute on <xsl:output>

Just as you can say:

   <!-- I'm not a python programmer, take example with grain of salt -->
   <xsl:sort data-type="fourthought:pythonNumber"/> 


  <xsl:output method="fourthought:mySuperSerializer"/>

you follow this same approach and do something like:

  <xsl:script language="fourthought:python"/>

| Why is this necessary?

It's not. You can continue to provide proprietary ways
to specify extension functions if you choose. See the
editors not in section 14.4"

   Ed Note: Make sure that it is clear that it is
            allowed to call extension functions
            without using xsl:script to define them.

| "When a function implementation is provided locally in the content of the 
| xsl:script element, the src attribute must not be specified."
| This language means that a stronger statement has to be made than
| "XSLT processors are not required to support any particular language binding. 
| xsl:script elements with language values not supported by the processor are 
| ignored."
| It should also point out that the processor need not check any conformance 
| constraints made with regard to xsl:script elements in an unsupported language 
| binding.  Basically, that "ignore" is not clear as to whether it refers to 
| structure or processing.

This is a fair point that should be clarified. For easiest tracking, please
send this point in a separate email to xsl-editors@xxxxxx so it's archived
in an easy-to locate place.

| It is also unclear as to how xsl:script interacts with fallback.  If there is 
| a script element and my processor does not not support it and there is a 
| fallback for that element, can I ignore the fallback and use a separately 
| registered extension module for that namespace URI?

I defer to James on this, but I believe the intent is that
if the stylesheet's version="1.0", then you do fallback as normal on <xsl:script>
since it's not a recognized element in the xsl namespace.

If the stylesheet's version="1.1", then I do not believe fallback applies
since it *is* a recognized element in the XSLT 1.1 spec. I believe it must
simply be ignored.

Steve Muench, Lead XML Evangelist & Consulting Product Manager
BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
Author "Building Oracle XML Applications", O'Reilly

 XSL-List info and archive:

Current Thread