Subject: Re: My favourite XSLT enhancement requests From: "Steve Muench" <smuench@xxxxxxxxxxxxx> Date: Fri, 15 Sep 2000 14:37:26 -0700 |
| For instance, section 3 of this document called "Requirements for | *Portable* Extension Function Implemenations" requests, in particular: | | - "... Extension function implementations MUST be allowed both inline as | well as externally ..." | - "...It SHOULD be possible to return an object of any host-language | type from the extension function ..." | - "...It SHOULD be possible to pass an object of any host-language type | to an extension function ..." | | but, on the other hand, | | - "... A processor SHOULD NOT be required to implement the portable | extension function binding for any particular language ..." | | Does it really propose *portable* extension implementations? It's a requirements document so it of course does not propose the implementation of the requirements but the requirement is that it be *possible* to write a stylesheet requiring extension functions that can be portable across XSLT processor implementations. Right now, the situation is as follows: (1) The extension function mechanism is optional in XSLT 1.0. (Lightweight implementations of XSLT in a palm browser might rightfully decide that implementing extension functions is not a feature that they require, and the optionality of the extension function mechanism supports this implementation) (2) You in general cannot write stylesheets with extension functions that are portable between any two vendors XSLT engines. The working group is trying to address portability issues raised by users on the XSL-List about the two most popular languages for extension function implementations which existing XSLT processors implement, making (2) above possible without changing (1) above. | In particular, how the XSLT stylesheet that contains an embedded Java code | should be ported to the XSLT processor that does not (and SHOULD NOT be | required) to support Java? If XSLT 1.1 were to provide an implementation of the requirements above, this would mean the following: -> A stylesheet that requires extension functions using one of the specified languages can be run on any XSLT 1.1-compliant processor that supports the same language binding for extension functions. | From my point of view, something quite opposite is needed to implement | truly portable extensions. In particular: | | - the stylesheet must not contain any language-specific code (this rules | out both inline implementations of extension functions and access to | language-specific data types) The requirements do not preclude the situation where all language-specific code is specified outside the stylesheet itself. In fact is says it MUST be possible to specify the extension function implementation outside. This could be your preferred way of working. | - the way to specify abstract (language-independent) interfaces between | stylesheets and code implementing extensions must be provided This would done in the spirit of DOM, SVG, and other specs. By specifying the interface in IDL, and providing language bindings for this generic interface (initially) in Java and ECMAScript, allowing for other language bindings in the future. | - the interface specification must be simple and intuitive (stylesheet | authors SHOULD NOT be programmers, therefore something like OMG IDL | probably would not work) There is no requirement that stylesheet authors necessarily be the same person that authors extension function implementations. In fact, the requirements are designed to allow developers more comfortable with programming to implement the extension functions and provide the extension functions as a library to be used by stylesheet authors. The requirement is that they must work like built-in functions so that it is possible for stylesheet authors to use extension functions in the same, natural way as built-in functions. | - the interface specification should be ...mmm... object-oriented (the | stylesheet author should be able to access properties and methods of the | abstract objects implemened elsewhere) | - the bindings of the abstract interface to the particular languages | should be defined, however, these bindings should be hidden from the | stylesheet authors Not all possible implementation languages that might want to be used for extension functions are object-oriented languages. So using IDL-interface-based contracts are a way that have proven successful for other W3C specifications to communicate the abstract requirements so that consistent language bindings can be developed in any language. | My original proposal is offering a tool which might be inferior to "all | of best known XSLT engines", but already supports the portable approach | to XSLT extensions and could be used *now* to test various ideas about | XSLT extensibility. As with all feedback from the XSL-List community, your implementation experience in making such a tool available to evaluate might provide valuable input to the XSL working group. ______________________________________________________________ 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: My favourite XSLT enhancement r, Alexey Gokhberg | Thread | Re: My favourite XSLT enhancement r, Alexey Gokhberg |
Re: Using xsl:if to determine if a , Gary L Peskin | Date | Test (Again), uche . ogbuji |
Month |