Subject: Re: [xsl] RDDL as a delivery vehicle for XSLT extensions? From: "Steve Muench" <Steve.Muench@xxxxxxxxxx> Date: Fri, 2 Mar 2001 09:16:42 -0800 |
Jenni, I'm speaking only for myself in these comments, nor for Oracle or the XSL WG. :-) | > Modulo the additional info about args and return types, see your | > <xbind:module> plus multiple <xbind:implementation> children as | > isomorphic to the sample number of <xsl:library> elements. They both | > have "a-language-independent-uri-that- refers-to-functionality". | > They both list multiple implementations of that functionality. | | Then you wouldn't object to changing XSLT 1.1 so that it uses Clark's | idea instead? ;) I pointed out the similarity only to illustrate how the existing proposal already provides the same mechanisms that Clark finds desireable. Whether or not the "language-independent-uri-that-refers-to-functionality" appears in its own wrapping element or not is just a question of syntax sugar in my opinion. | Most important, I think, is that the provision of functions in | different languages is broken down *first* by functionality and | *second* by language rather than (with xsl:script in the XSLT 1.1 WD) | *first* by language and *second* by functionality. | | This is comforting because it puts the emphasis on portability, on | having multiple implementations of the same function. I respectfully disagree with this. The working draft is broken down first by "language-independent-uri-that-refers-to-functionality", then by implementation binding. It's just using the value of the uri as the "grouping" criteria, if you will, as opposed to introducing an enclosing element to wrap the one or more bindings. Does having a wrapping element which allows multiple language binding implementations versus not having a wrapping element but just the same allowing the exact same capability of providing multiple language bindings based on the URI significant added value, I would argue no. | important extra level of modularity because a new implementation of a | function can be slotted in without having to do anything to the | stylesheet. I missed in Clark's proposal how new implementations could be added without adding an extra <xbind:implementation> element inside the <xbind:module> element in the stylesheet. If what you're saying is that a stylesheet could <xsl:import> another stylesheet that contains the <xbind:module> element, and in doing that would prevent the *importing* stylesheet from having to change to introduce a new binding, well then that can be accomplished with the existing proposal, too. Just have the importing stylesheet <xsl:import> a (to coin a new term) "library module" stylesheet that only consists of: <!-- A Library Module Stylesheet --> <xsl:stylesheet xmlns:xsl="..." xmlns:cool="language-independent-uri-that-refers-to-func"> <xsl:script implements-prefix="cool" language="x:XXX" src="uri"/> <xsl:script implements-prefix="cool" language="y:YYY" src="uri"/> <xsl:script implements-prefix="cool" language="z:ZZZ" src="uri"/> </xsl:stylesheet> Then, the importing stylesheet doesn't have to change when a new implementation gets "slotted in" to the library module stylesheet. Did I miss something in Clark's proposal that handles this in a radically more productive way? | Finally, I think there's an appeal in the fact that the code itself is | not embedded in the stylesheet. Clark's proposal showed both by-ref and embedded. It should be up to the user who knows whether this little function that they need to write will live in an external file or be embedded. If it's a one-line function it's a little overkill to force the user to save it into a separate *.js file. If you are a user that *hates* embedding, then none of your stylesheets will ever, ever use embedding. | What are the benefits that you see to the current xsl:script | definition as opposed to the idea of a separate binding? The current proposal already separates the notion of a URI the represents functionality in a language-neutral way, and the idea of separate implementation bindings, and it supports the ability to modularize the definition of these bindings into a separate "library module" stylesheet, if this is desired. Therefore, having tried to reverse-engineer your requirements out of Clark's alternative syntax proposal, the current proposal appears to satisfy all of these requirements to me. ______________________________________________________________ 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] RDDL as a delivery vehicl, Jeni Tennison | Thread | Re: [xsl] RDDL as a delivery vehicl, Jeni Tennison |
Re: [xsl] RDDL as a delivery vehicl, Alexey Gokhberg | Date | Re: [xsl] RDDL as a delivery vehicl, Joe English |
Month |