Re: [xsl] XSLT and Unicode character functions --XSLT v 1.1?--

Subject: Re: [xsl] XSLT and Unicode character functions --XSLT v 1.1?--
From: "Michael Beddow" <mbnospam@xxxxxxxxxxx>
Date: Wed, 31 Jan 2001 10:43:54 -0000
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
> > > > 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
> > 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

 XSL-List info and archive:

Current Thread