Subject: Re: [xsl] XSLT 1.1 comments From: Alexey Gokhberg <alexei@xxxxxxxxxx> Date: Mon, 12 Feb 2001 09:58:47 +0100 |
Uche Ogbuji wrote: > > In the xsl:script section, please drop the "ecmascript" | "javascript" | > "java" nonsense from the "language" attribute specification. This just > inflames those of us who worry about the W3C's language bias. Popularity is > not even a good excuse, since VB is probably a more popular scripting language > for XSLT extensions than Java. It's also totally unnecessary. > > In general, I think the re-introduction of xml:script is execrable. XSLT 1.0 > had perhaps the most elegant extension model possible, and xsl:script ruins > this by destroying the opacity of extensions to XSLT processors. Exactly. Re-introduction of <xsl:script> ruins interoperability and standartization. What is the difference bethween the following two XSLT 1.1 stylesheet fragments: <xsl:script> . . . Some Java code here . . . </xsl:script> and <xsl:script> . . . Some language X code here . . . </xsl:script> where X is a programming language other than ECMAScript, JavaScript, or Java ? The answer is, that the first construction is a STANDARD one, while the second is NOT. In fact, the second construction is not better than something like <my-own-xsl-extensions:language-X-code-embedded-here> . . . Some language X code here . . . </my-own-xsl-extensions:language-X-code-embedded-here> Both constructions are NOT covered by XSLT 1.1, and both contain vendor-specific XSLT extensions. > ... Language > bindings may make sense in the realm of CORBA or DOM, where the actual > expression of the program is done in the bound language, but XSLT is XSLT, and > introducing the need for language bindings only reduces general > interoperability while giving a small boost to interoperability between small > axes of implementations. > Exactly. Remove <xsl:script> from XSLT 1.1, and the need for the specific language bindings in the core XSLT specification will disappear. The minimal abstract model covering all extension programming languages can be introduced, and XSLT specification can describe extensions in terms of this model. With this approach, language bindings become purely an implementation issue. If needed, separate specifications could be created for the particular languages, but the core XSLT specification is certainly not a right place for the implementation-specific stuff. Retain <xsl:script> - and soon there will be a lot of stylesheets written 50% in XSLT and 50% in Java, which are STANDARD and probably even more stylesheets written 50% in XSLT and 50% in VB, C#, etc, which are NON-STANDARD. Would it really improve interoperability? And why Java is in more privileged position than any other language? > > ... In fact, I get the impression that it was the > Saxon-OracleXSL-Xalan-J axis that brought this about. > Well, the present XSLT 1.1 draft looks more like a CONVENTION BETWEEN VENDORS OF JAVA-BASED XSLT PROCESSORS, rather than the vendor-neutral, cross-platform specification. Probably, nothing will change until "smaller axes of implementation" will lose their patience and form a single bigger axis, in order to create, implement, and promote specifications for XSLT extensions, which support true interoperability. Regards, Alexey Gokhberg Unicorn Enterprises SA XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
xsl:script considered dangerous -- , Clark C. Evans | Thread | RE: [xsl] XSLT 1.1 comments, Adam Van Den Hoven |
Re: [xsl] treeViewer, Jiri Jirat | Date | RE: [xsl] choose - when problem, Jo Kong HO |
Month |