Re: [xsl] XSLT 1.1 comments

Subject: Re: [xsl] XSLT 1.1 comments
From: "Steve Muench" <Steve.Muench@xxxxxxxxxx>
Date: Mon, 12 Feb 2001 23:24:12 -0800
| I think it's *very* important to note that even if "Python" and "C" were added 
| as first-class bindings in the spec, I'd still be against xsl:script.  Note 
| that there will soon be 3 Python XSLT processors and I still don't believe 
| that XSLT 1.1 adds anything to help us standardize beyond what XSLT 1.0 
| provided.

Let's take a simple example: Write an extension function in
python to tokenize a string and return a node-set of elements
containing the tokenized values.

If three vendors each produce python XSLT engines, and all three
vendors allow extension functions in python, and each of the three
vendors defines its own contract for how extension functions can
access XSLT Processor context information, and all three vendors
define different approaches for returns Node-Sets from extension
functions, then... you have the XSLT 1.0 situation.

When I try to use a stylesheet that was developed with
python-xslt-processor-1, and which uses this extension function,
it will only work with processor-1, not with the other two.

If the three vendors customers asked them to get together and
"standardize" the way that Python developers should write XSLT
extension functions, then the three vendors would have to
get together to:

  (1) Agree on a way to associate a namespace with an extension
      function implementation

  (2) Decide on a namespace for the extension element that
      associates a namespace with an extension function implementation.
  (3) Agree on an interface for the XSLT processor context
  (4) Agree on the way that XPath data types map to Python types
  (5) Agree on the way that trees of nodes are presented to
      extensions and how extension can return trees of nodes
  (6) Agree on an algorithm for uniquely selecting from among
      overloaded functions
  (7) Decide whether it is useful for Python extension functions 
      to return any Python object as the return value of an extension
      function, so it may be passed to another python extension
      function in the same namespace.

This is precisely the work that the XSL WG did for XSLT 1.1.

XSLT 1.1 defines a language-neutral way to do (1) via <xsl:script>

For step (2), we decided it would go in the XSL namespace.

For steps (3)...(7), the group voted to provide bindings for IDL, Java,
and ECMAScript.

| format-number() is another case in point of this.  It  causes *real* pain 
| when an implementor has to find away to implement such an 
| awkward mechanism when his language has perfectly useful, and far more mature, 
| numerical formatting constructs.  I bet you implemented format-number() in 
| OracleXSL in ten minutes.  It has taken the 4XSLT implementors a dreadful 
| amount of work.

Oracle has both Java and C implementations. I did not hear the developers
of our C implementation complaining about format-number(). They just
implemented the behavior as noted in the spec.

| The XSLT 1.1 charter talks about pressure from the community for language 
| bindings, but the only talk I've heard about it has been from Java 
| implementors.  It *appears*, and I might be wrong, that this XSLT 1.1 draft 
| was produced without thinking of the general ramifications of the changes 
| outside of the Java interest.

This is the farthest from the truth. Lotus/IBM/Apache, Oracle, Microsoft
and others also have C/C++ implementations. The intent of the design of 
the XSLT 1.1 extension functions was done to allow any languages to
be used. The group voted to pursue language bindings for Java and
ECMAScript. OracleXSL doesn't support ECMAScript, for example.
Microsoft XSLT doesn't support Java. 

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