Subject: Re: [xsl] XSLT 1.1 comments From: "Steve Muench" <Steve.Muench@xxxxxxxxxx> Date: Mon, 12 Feb 2001 13:45:35 -0800 |
| If I want to assert that my XSLT processor is 100% XSLT 1.1 compliant then | anyone who uses my processor should be confindent that it will correctly | transform XML using any XSLT 1.1 compliant document. This is already a tall order. If you modify this statement to say: anyone who uses my processor should be confindent that it will correctly transform XML using any XSLT 1.x compliant stylesheet which does not use optional features of XSLT 1.x then I buy the premise. Already, the existence of the optional extension functions in XSLT 1.0 means you cannot make a blind guarantee like that. | Now it just so happens that I wrote my processor in fortran. Either I | am not going to be able to claim to be compliant OR I am going to have | to spend thousands of hours mapping java to fortran. You've misunderstood here. Your hypothetical FORTRAN-based XSLT 1.1 processor does not need to implement extension functions at all. If it *does* implement Java (why would it, but *if* it were to implement Java extension functions), then it would have to implement its Java language binding according to the spec. | Now, if there is no xsl:script tag, then I don't have to worry about making | those mappings because they are not part of the XSL namespace. This way, ALL | XSLT 1.1 transforms will work (I'll make sure that other namespaces fallback | gracefully). The fact of the matter is, NOT defining a language mapping is | more interoperable than having one. Same comment as above. As soon as a user begins to use extension ELEMENTS or extension FUNCTIONS in a stylesheet, all bets are off for portability. | Not everyone needs to or even want to implement JAVA... Just ask Microsoft. | In fact, other language bindings might be more useful than JAVA. Indeed. I don't expect Microsoft to implement the Java language binding in an eventual XSLT 1.1 compliant processor. Since they already support ECMAScript extensions, they would likely support those (but this is still talking hypothetically, as I know nothing about their implementation plans). | Now if having a common language mapping is so utterly important, then move | it into another namespace (XSL-Scripting). <xsl:output> is an example of an element in the XSL namespace which a processor is free to ignore if it does not do serialization of the result tree. Section 16 of XSLT 1.0 spec says: If an XSLT processor outputs the result tree, it should do so as specified by the xsl:output element; however, it is not required to do so. So there already are examples of <xsl:*> elements that are not mandatory. ______________________________________________________________ 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, Adam Van Den Hoven | Thread | RE: [xsl] XSLT 1.1 comments, Peter Flynn |
[xsl] recursion troubles , Eric Vermetten | Date | Re: [xsl] Stopping Saxon searching , jim smith |
Month |