Subject: [xsl] RDDL as a delivery vehicle for XSLT extensions? From: "Clark C. Evans" <cce@xxxxxxxxxxxxxx> Date: Thu, 1 Mar 2001 15:37:35 -0500 (EST) |
I have a question. What is the primary reason for xsl:script? With XSLT 1.0 we _already_ have extension functions. With XSLT 1.1, we will have a Java and ECMA Script bingings (perhaps in an appendix?). So, what value _does_ xsl:script provide? I think this is the answer: xsl:script provides a delivery vehicle for XSLT extensions. The question becomes: Are their other solutions to this problem that could be more platform/language neutral? I think yes. I think an RDDL mechanism for looking up and downloading extensions based on a language-nutrial interface would do it. Thoughts? Clark ---------- Forwarded message ---------- Date: Thu, 1 Mar 2001 15:29:32 -0500 (EST) From: Clark C. Evans <cce@xxxxxxxxxxxxxx> To: "Bullard, Claude L (Len)" <clbullar@xxxxxxxx> Cc: Evan Lenz <elenz@xxxxxxxxxxx>, Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx>, xml-dev@xxxxxxxxxxxxx Subject: RE: [xsl] ANNOUNCE: Petition to withdraw xsl:script from XSLT 1.1 On Thu, 1 Mar 2001, Bullard, Claude L (Len) wrote: > But I am concerned that getting rid of the extension element altogether > tosses the baby out with the bathwater. This issue of extensibility > and component support is bedeviling a lot of web app languages these > days. An almost one for one duplicate of this is raging on the VRML > list. On one side, some want no extensions. On the other some demand > extensions. To quote from the opening of the petition: XSLT provides an extension mechanism whereby additional functionality can be identified with a URI reference and implemented in a manner defined by a particular XSLT processor. This mechanism provides an opaque layer between the extension function's usage and its implementation -- allowing for many implementations of an extension function regardless of language or platform. This extension facility provides a rich playground where new features can be prototyped and even put into production. However, to balance this much-needed flexibility, the syntax makes it clear that such added functionality is, in fact, an "extension" and therefore may not be portable across XSLT implementations. I don't think any of the petitioners seriously doubts the importance of the extension mechanism. The difficulty is that xsl:script does extension by "embedding" rather than through a component interface which can be language independent. Thus, an "extension function delivery vehicle" is the baby, it is the embedded scripting that is the bath water.... IMHO, what we need is a way to specify extension components, and then a way to locate (RDDL?) an implementation of a particular extension for a particular language/platform combination. > It seems best to ask for that, but expect a compromise such as relabeling > or rewriting to deemphasize the binding or to make it clear this is not > de facto standardization of two vendor products. Results and perceptions > will vary but I don't see a good alternative. No. I don't think re-writing will do it. Embedding is the problem. Embedding should just be seen as a "implementation delivery vehicle", we can do much better. ;) Clark XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] <xsl:include> and Oracle , Ellis, Graham | Thread | RE: [xsl] RDDL as a delivery vehicl, Michael Kay |
Re: [xsl] ANNOUNCE: Petition to wit, cutlass | Date | [xsl] Selecting /getting only one n, Tapan Nanawati |
Month |