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 http://xml.org/posix 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. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] XSLT 1.1 comments, Francis Norton | Thread | Re: [xsl] XSLT 1.1 comments, Steve Muench |
[xsl] Copying Groups of Attributes, Ciaran Byrne | Date | Re: [xsl] XSLT 1.1 comments, Uche Ogbuji |
Month |