|
[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
> If I read this correctly, the problem is not > the script element but the perceived requirement > that Java (a Sun product) and JavaScript (a > Netscape/AOL product) are required to be supported, > thus engendering a product bias into a language > neutral specification? Actually, from the petition text: "Success of this extension mechanism has brought about request for change by several parties. One change is the official Java and Javascript extension function binding. Although this petition does not specifically challenge this addition, some question the wisdom of this decision. An official binding could encourage wholesale importation of constructs from Java and Javascript into XSLT without thought as to how those constructs would or should be supported in XSLT proper. A second change, the addition of xsl:script, is what we challenge with this petition." The Java and Javascript language bindings are a slightly different, if closely linked issue to the xsl:script issue. My main objection to the Jav and ECMA bindings are that they pollute the main XSLT spec and are given unseemly prominence therein, rather than being completely relegated to an appendix, as in the DOM binding. (Incidentally, someone has pointed out our comment on the DOM binding in the petition text. This is an error that escaped editing. Besides my wonder as to whether the DOM WG would give published prominence to other bindings, I don't have any problem with the way DOM has provided Java and ECMA bindings in the appendix). But the petition itself is mostly aimed at xsl:script, and the harm it can introduce by prematurely mixing up the clean layering between XSLT proper and conforming extensions. > Same problem with X3D. The retort is > that "We don't insist that an implementor > support Java. We insist that if they support > Java, they use this binding." The problem with xsl:script is that it makes it very easy to just dump the Java right into the XSLT itself, causing a maintenance problem for users and unfortunate pressure for XSLT implementers to implement language scripts for the more popular languages. What's so much the worse is that it's premature. XSLT is very young for such invasive tinkering. The WG cites complaints by extension users about incompatabilities between processors, but no effort has been made to address this issue without the drastic resort of xsl:script. If XSLT implementers have users clamoring for standardized extensions, they can band together to produce these. I think that the other end of the spectrum: sophisticated XSLT users who want to write their own extensions in one Java processor and have them ported to another, are a much rarer breed, and that the Java implementers can standardize this separately from XSLT itself. > The further > explanation has been unofficially that failing > to support Java has seriously hurt the acceptance > of VRML. In VRML, the required support was > for EcmaScript and VrmlScript. Neither satisfied > the developers who wanted object-oriented language > extensibility. Well, XSLT 1.0 is *very* successful. I don't think anyone can say that a 100,000 volt zap is required to keep it alive. -- Uche Ogbuji Principal Consultant uche.ogbuji@f... +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python
|
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








