[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: RDDL as a delivery vehicle for XSLT extensions?
Hi Steve, > I'm speaking only for myself in these comments, nor for Oracle > or the XSL WG. :-) Naturally :) I'm speaking only for myself, and not for the no xsl:script petitioners. I probably shouldn't have said anything, particularly as I don't feel strongly either way at the moment... > | 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. I think that you've misunderstood me (or I've misunderstood you). The grouping that I was referring to was the fact that within a particular (namespace-identified) set of functions, Clark's original proposal broke them down by: * namespace contains many * functions has many * implementations in different languages All of the implementations of the num:min() function are grouped together, as are all the implementations of the num:max() function and so on. Under XSLT 1.1, the functions are broken down as: * namespace has many * implementations in different languages which involve many * functions All the implementations in Javascript (for the particular namespace) are grouped together, as are all the implementations in Perl. Of course that's changed in the more recent summaries, so obviously this wasn't as important as I thought it was ;) > 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. I'm not sure, but I think that the above and the rest of what you said imply that we have different pictures of what Clark's proposal involves. As far as I understand it, the idea in Clark's proposal is that in the stylesheet you have something along the lines of: <xsl:script implements-prefix="namespace-prefix" binding="URL" /> The XSLT processor resolves the prefix to identify the namespace for a bunch of functions. It then uses (e.g.) RDDL to identify the module definition, which has the links to the various implementations - it isn't situated in any stylesheet, but in a separate file. Let's take an example. I author 50 stylesheets for an organisation on the understanding that they're going to be using them client-side with MSXML. Each of these stylesheets involves some basic date manipulation functions that I write in JScript. With xsl:script, I place the following in each of my files: <xsl:script implements-prefix="date" src="date.js" /> There is a tight binding here between the namespace for the function and the implementation of it. With Clark's proposal, I put: <xsl:script implements-prefix="date" binding="date.xml" /> where date.xml is an XML file that holds various information about the date functions, including a pointer to the JScript implementations that I've constructed (or those functions embedded) (i.e. the xbind:module element is the document element). Now the organisation turns round to me in the way that organisations do and says that they're not using MSXML any more, they've decided to use Saxon and the stylesheets don't work no more. That's because Saxon doesn't support JScript, I say. Fix it, they say. With XSLT 1.1 xsl:script, I have to go through those 50 stylesheets and replace all the xsl:script elements (or add a new one). Under Clark's proposal, I only have to edit date.xml - I add links to the Java implementations of the functions. I don't have to touch the stylesheets at all. Yes, all the hassle could have been avoided if I'd put the xsl:script in an imported stylesheet. But if it's good practice to place the binding between a namespace and an implementation in a separate stylesheet in case of this kind of eventuality, and that stylesheet isn't going to hold anything else, then it isn't really a stylesheet anyway - you may as well create a different kind of file to hold that kind of information. You can even get it to hold other interesting info as well... > Clark's proposal showed both by-ref and embedded. Yes, but the embedded code wasn't embedded in the stylesheet, but in the separate file containing binding information, as far as I understood it. That seems to be important to the no xsl:script petitioners. But having said that, you could say that the reference from xsl:script in Clark's model could be a local link to a local module definition that held embedded code, in which case it's right there in the stylesheet and ask why that's so different. I don't think there's a good answer to that. > 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. Well, one of the issues that's been raised about xsl:script is the fear that it will lead to users always reverting to a language they can handle rather than coming to know the joys of using XSLT. So I think that, to the no xsl:script petitioners, the fact that you have to jump through all those hoops for your one little function is a benefit because it will discourage people from opting out to other languages when they could use XSLT. I guess it's a bit of a libertarian issue - should you allow people to do all the things that they want to do or make it harder for them to do the things that aren't good for them? Personally, I'm a libertarian at heart so don't find this a particularly persuasive argument (though sometimes when I see yet another post about disable-output-escaping I think about reviewing my philosophy). Anyway, I only wrote to object to your assertion that the two approaches were basically the same - there must be some differences or the no xsl:script petitioners wouldn't find xsl:script so objectionable (even if the differences are in terms of structure and language rather than anything to do with functionality). Now I'm just trying to understand the pros and cons of these two possibilities so that I can make an educated decision about whether to sign this petition. Cheers, Jeni --- Jeni Tennison http://www.jenitennison.com/ XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|