|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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
|
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
|
|||||||||

Cart








