Re: [xsl] XSLT 1.1 comments

[Alexey Gokhberg <alexei at bluewin dot ch>]

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