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 http://www.oreilly.com/catalog/orxmlapp/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XSLT 1.1 comments, Uche Ogbuji | Thread | Re: [xsl] XSLT 1.1 comments, Tobias Reif |
Re: [xsl] XSLT 1.1 comments, Steve Muench | Date | RE: [xsl] Can XSLT output Barcode c, Jarno Elovirta |
Month |