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:28:40 -0700
> Daniel Veillard wrote:
> > 
> >   As you can see the extension was deemed more important than the
> > portability, and this totally in opposition to what seems the main
> > point raised in the introduction:
> > 
> > ----------
> > "The XSLT user community has consistently voiced the opinion that the non-portability of stylesheets is a key problem."
> > "The primary goal of the XSLT 1.1 specification is to improve stylesheet portability."
> > ----------
> > 
> > unfortunately the way they suggest to achieve this is by defining mapping
> > for targetted language.

This is also how I see it, and I also find it unfortunate.

> I think there are two main use cases here - [1] extension functions for
> general processing, and [2] extensions for communicating with external
> systems, including the OS.

Before I get to the rest of your message, I'd like to point out that both 
layers can be handled in XSLT 1.0 quite handily by communication between XSLT 
extension library authors *without* muching with the XSLT spec.  For instance, 
POSIX could be used as the OS access API and extension writers could set upon

or whatever as the namespace URI, and then disseminate extension 
implementations for different processors.  Then if the Java folks had 
standardized their "language binding", the job would be less because all the 
Java processors could ahve a posix library added with one code base.  This 
looks like the goal of the XSLT WG, but where they go wrong is in not 
recognizing that these matters should be dealt with at higher layers than the 
XSLT specification itself.

> The XSLTR 1.1 proposal addresses use case [2], which has to be
> non-portable.

Not necessarily, as I explained.

> Use case [1] *could* be solved portably by providing a
> syntax-sugar solution for writing XST function in XSLT, but in the
> absence of such a feature, requirement [1] will be captured by solution
> [2], so anyone who wants to add - for example - date processing will be
> forced to do it in a non-portable way.

Yes, and this is the problem I see.

> I invested a lot of time and effort into doing things the XSLT way,
> however quirky it might seem to the uninitiated, on the grounds that it
> was portable and it was the right thing. Now the message is that if we
> want to write extension functions, XSLT is the wrong thing. I'm starting
> to feel disillusioned.

Agreed.  Basically, it looks as if the WG is looking to turn XSLT into nothing 
more than a cute little Java or ECMAScript library for XML-based tree 
processing, which is odd considering the success it has found as a language in 
its own right.

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