[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XSLT and Unicode character functions --XSLT v 1.1

Subject: Re: XSLT and Unicode character functions --XSLT v 1.1?--
From: "Michael Beddow" <mbnospam@xxxxxxxxxxx>
Date: Wed, 31 Jan 2001 10:43:54 -0000
xalan c xslt functions
On Wednesday, January 31, 2001 8:02 AM
Daniel Veillard wrote:

> On Tue, Jan 30, 2001 at 09:11:03PM -0000, Michael Kay wrote:
> > > > XML/XSLT is, internally (and externally through different
> > > > encodings), based on Unicode character handling.
> > > > Then wouldn't it be logical and desirable that the two
functions
> > > > given here be part of the standard XSLT function reportoire?
> > > > (e.g. XSLT v1.1)?
> >
> > Once we have a standard Java binding then the whole Java class
library will
> > become part of the standard XSLT function repertoire. Isn't that a
better
> > way to handle such requirements?
>
>   No, sorry.
>   There is a strong difference between a mandatory feature and
> one which is not. Don't put anything important to XSLT processing
> into an optional feature.
>   Moreover extensing this Java-only tendancy of XSLt is really bad,

Once again, I have to agree. For one of the things I'm doing at the
moment (which also happens to have PCDATA from all planes in the
Unicode BMP) no Java-based solution is yet fast enough. Xalan C++ is
the only package that has the right combination of speed and
conformance. I want to see all the character-handling I need built
into XSLT itself, not reliant on what the underlying platform
provides. (And I also want to keep the choice of using client-side
XSLT on MS platforms, once their much improved engine becomes part of
a default install, as it surely will before long.) I think two factors
about parts of the XSL community mean this issue isn't getting the
priority it deserves.
1) A lot of people here are from a document-management background, for
whom rendering speed in real time isn't of the essence. They can wait
around for a Java VM to get its act together and don't need to worry
about its resource demands either.
2) Though no longer US-English-centric, there's quite a lot of
Latin-script-centricity shaping people's priorities. We really need to
have standard and rock-solid handling of ALL writing systems encodable
in utf-8, (inclduign appropriate collation etc etc)  in the core of
XSLT itself, otherwise the key aim of  complete data
interchangeability will not be achieved
------------------------------------------
Michael Beddow
http://www.mbeddow.net/




 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.