Re: [xsl] XSLT 1.1 comments

Subject: Re: [xsl] XSLT 1.1 comments
From: Uche Ogbuji <uche.ogbuji@xxxxxxxxxxxxxxx>
Date: Mon, 12 Feb 2001 17:47:45 -0700
> | Uche Ogbuji wrote:
> |
> | "If an external object is passed to an extension function with an 
> | expanded-name whose namespace URI is different from the namespace URI of the 
> | expanded-name of the extension function that returned that external object, 
> | the behavior is implementation-dependent."
> All this means is that since:
>   (*) XSLT 1.1 allows each extension function prefix
>       to be implemented by one or more languages, and since
>   (*) XSLT 1.1 allows a processor to freely pick from
>       among multiple language implementations that might
>       exist, which language it *chooses* (if any) to support,
>       and since
>   (*) XSLT 1.1 constrains the processor (once it's chosen
>       which language implementation it prefers) to consistently
>       pick the same language implementation for the same prefix
>       for the duration of a single stylesheet "run"

I'm sorry, but I don't see how the paragraph I quoted translates into your 
three bullet points.  You don't even mention "external object" in your bullet 
points.  I am talking about the oddness of the language that selectes one 
aspect of external objects as "implementation-dependent" when clearly 
everything about external objects is "implementations dependent".

BTW, I think  this is about as powerful argument as one needs that they do not 
belong in the XSLT spec.

> that passing the return value of a function foo:function1()
> into a function from a different namespace like bar:function2()
> is implementation-defined because the chance exists that
> namespace prefix "foo" is implemented in ECMAScript and namespace
> "bar" is implemented in Java, but within one stylesheet run
> all functions in namespace "foo" will be executed using the
> same language and all functions in the "bar" namespace will
> be executed using the same language.

Again, what is so special about parameters in this case?  Everything to do 
with them is implementation (dependent.

> | Uche Ogbuji wrote:
> | >
> | > > introducing the need for language bindings only reduces general
> | > > interoperability while giving a small boost to
> | > > interoperability between small axes of implementations.
> | > >
> XSLT 1.1 does not introduce the *need* for language bindings.
> Extension functions continue to be a completely optional feature.
> What it *does* say is that:

If this is true, then the "language bindings" should be removed from the spec, 
since they are otiose.

>   -> if two conforming XSLT 1.1 processor implementations both
>      have elected to implement the ECMAScript language for extension
>      functions, then developers can expect that they'll implement
>      the "contract" between the XSLT processor and the ECMAScript
>      extension function implementations in a compatible way.

Why does this contract belong in the XSLT spec?  There are many perfectly good 
places to publish ECMA conventions.

> and similarly:
>   -> if two conforming XSLT 1.1 processor implementations both
>      have elected to implement the Java language for extension
>      functions, then developers can expect that they'll implement
>      the "contract" between the XSLT processor and the Java
>      extension function implementations in a compatible way.


> In XSLT 1.0, developers who today extend XSLT with extension
> functions in ECMAScript using Alexey's Unicorn processor cannot
> run them with Microsoft's MSXSL3 processor. They both support
> ECMAScript extensions, but they do it in incompatible ways.

But Unicorn and Microsoft can sort this out without any help from the XSLT WG. 
 Why can't the Java implementors do so as well?

> If both Microsoft and Unicorn produce conformant XSLT 1.1 processors,
> then these stylesheets with ECMAScript extension would run 
> interchangeably on both.

And what if C++ or Visual Basic, and not ECMA, is the most convenient language 
for the unified extensions?

> Of course, the ability to *avoid* using XSLT extension functions
> remains exactly as in XSLT 1.1. So, for ultimately portability
> there is no change at all: simply avoid extension functions.
> This situation has surely not be made more complicated by XSLT 1.1. 
> However, the lives of developers combining XSLT with ECMAScript
> and Java extensions *has* improved because now even if they *do*
> use extension functions, their stylesheets can still be portable
> across implementations that implement extension function language.
> The spec allows extension function implementations to be provided
> in multiple languages, so a stylesheet developer can produce
> a stylesheet with *BOTH* an equivalent ECMAScript and a Java extension
> language implementation, and then, for example, a stylesheet that
> uses extensions could run under SAXON (which might select to use
> the Java extension function implementation) as well as Microsoft's
> MSXSL3 and Unicorn which both might offer only ECMAScript language.

Again, I see no gain over XSLT 1.0, which allows all these advantages properly 

> | In XSLT 1.0, the vendor of any particular XSLT processor can specify and
> | implement the proprietary mechanism for building custom extensions.
> This is precisely the problem. This ability to implement everything in
> a totally proprietary way means nothing can ever be portable in the
> extension function world.

Absolutely false.  See my last message responding to Francis Norton for the 
mechnism to sort things out without xsl:script.

> | In XSLT stylesheets, these extensions appear as XPath extension functions.
> | There are no platform-specific features contained in XSLT stylesheets
> | themselves. Potentially, a stylesheet using extension function can be
> | ported to any other XSLT processor, provided that this new processor
> | implements the adequate mechanism for building custom extensions. Of
> | course, extension functions must be re-implemented, but the XSLT
> | stylesheet itself remains unchanged.
> This is a rather theoretical argument. In practice, this has not
> happened, even though I admit that it's technically possible.

Have you considered that the reason this hasn't happened is because XSLT 1.0 
is only a year old?  In fact, all you have to do is nix xsl:script, and move 
the Java and ECMA "bindings" to the appropriate W3C NOTE, and your rebuttal 
instantly vanishes.

> | In XSLT 1.1, there is <xsl:script>, and there is Java as a standard
> | language for extension development. This invites to create XSLT
> | stylesheets containing mixed XSLT and Java code, which are portable only
> | between Java-based XSLT processors.
> All it does is allow developers who already are working in Java or
> ECMAScript for extension functions, to suddenly no longer be restricted
> to using their XSLT 1.1 compliant stylesheets with a single vendor's
> XSLT Processor implementation.

Again, why is the spec necessary for this?  XSLT is not a Java convenience 
library.  It is a language of its own right, and intersections with other 
languages should be dealt with in a properly layered manner.

> | Well, XSLT 1.1 indeed DOES improve interoperability in comparison to
> | XSLT 1.0 - for vendors and users of Java-based XSLT implementations. For
> | vendors and users of non-Java XSLT processors XSLT 1.1 offers NOTHING in
> | addition to XSLT 1.0.
> This statement is not true.
> In XSLT 1.1, since the <xsl:script> supports a 'language' attribute
> that is a QName-but-not-NCName, all you need to do is invent a
> convenient namespace prefix and then:
>    <xsl:script language="unicorn:ecmascript">

???  Don't you mean <xsl:script language="unicorn-and-microsoft:ecmascript">

Again, it offers nothing new to Unicorn, Microsoft or Python or Perl XSLT 
implementors.  It does offer to Java official standing as an XSLT extension 
language in the spec.

Uche Ogbuji                               Principal Consultant
uche.ogbuji@xxxxxxxxxxxxxxx               +1 303 583 9900 x 101
Fourthought, Inc.                
4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA
Software-engineering, knowledge-management, XML, CORBA, Linux, Python

 XSL-List info and archive:

Current Thread