[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?
On Sat, 3 Mar 2001, Jeni Tennison wrote: > 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 ;) What is important, from my perspective is: a) The functionality is the primary object, and it identified by an opaque, language independent URI that is unique in the current context. b) That the implementations and/or instructions for binding to an implementation need not be in the stylesheet itself, perferably it is a seperate xml structure independent of XSLT and re-useable by other specifications. c) The the method for obtaining an implementation of this functionality not be singluar, that is, only provided via xsl:script. Perhaps even allowing for functions to be used with only a namespace binding; assuming that an implementation is either built-in, in a local catalogue, or perhaps downloadable via RDDL. d) That the identifying URI also be coupled with a IDL like description of the module. e) Perhaps even the identifying URI is required to be a a globally unique URL that can be used to fetch via RDDL a catalogue of implementations, etc. But this may be too restrictive. > 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" /> Yes, actually, you could go one step further. The binding could be done entirely through xmlns:prefix="binding-url", skipping the need for xsl:script altogether. In the example below it is not > <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" /> Right, or even, perhaps just the following. <xsl:stylesheet xmlns:date="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). Right. Here the "date.xml" uri isn't globally unique, which is what I'd rather have. And then use a catalogue solution or built-in resolution to bind the functionality. > 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... Exactly. > > 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. Yes, this is important. But what is also important to me is that an implemenation be obtainable through multiple methods, not just relying on one local-lookup method. > 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. The difference is that in the proposal I was trying to explain (which is why Eugene's syntax is nicer) is that the binding file need not contain every possible implementation. That other mechanisms may be used by the xsl processor to obtain the implementation. Thus, the focus is really on the opaque functionality identifier and this is the primary difference. Thank you Jeni! ;) Clark 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
|