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

Subject: Re: [xsl] XSLT and Unicode character functions --XSLT v 1.1?--
From: Daniel Veillard <Daniel.Veillard@xxxxxxx>
Date: Wed, 31 Jan 2001 09:02:07 +0100
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 optionnal feature.
  Moreover extensing this Java-only tendancy of XSLt is really bad,
you will end up with XSLT-Java and XSLT-non-Java subset, i.e. arbitrarilly
adding a fragmentation, IMHO a bad thing.
  Extensibility is good to a point, if you turn it up to having the spec
being only a subset in practice, it's a direct threat to interoperability.

> Yes, I do know there will be processors that don't support the Java
> binding...

  As this was pointed out before, reimplementing a subset of the JDK
can lead to legal problems. If you want anybody to be able to implement
a given functionnality, you have to detail this functionnality in the
spec itself. I18N support is something considered core for all XML specs
if there is an I18N need this has to be added to the spec itself, not
into a laguage restricted optional feature, 


Daniel Veillard      | Red Hat Network
veillard@xxxxxxxxxx  | libxml Gnome XML toolkit | Rpmfind RPM search engine

 XSL-List info and archive:

Current Thread