- From: Daniel Veillard <Daniel.Veillard@imag.fr>
- Date: Sat, 13 Jan 2001 19:05:33 +0100
- To: Uche Ogbuji <uche.ogbuji@fourthought.com>, xsl-editors@w3.org
- Cc: alexei@bluewin.ch, xml-dev@xml.org
[ Cc'ed to xsl-editors@w3.org, is there any way to ease the work of implementors and avoid legal troubles w.r.t. number formatting support in XSLT-1.1 ? Daniel ] On Sat, Jan 13, 2001 at 09:50:44AM -0700, Uche Ogbuji wrote: > > "XSLT Transformations (XSLT) Version 1.0. W3C Recommendation 16 November > > 1999", section "12.3 Number Formatting" > > (http://www.w3.org/TR/xslt#format-number) states: > > > > "... The format pattern string is in the syntax specified by the JDK 1.1 > > DecimalFormat class ..." > > > > and > > > > "... The other attributes on xsl:decimal-format correspond to the > > methods on the JDK 1.1 DecimalFormatSymbols class. For each get/set > > method pair there is an attribute defined for the xsl:decimal-format > > element ..." > > > > and then: > > > > "NOTE: Implementations are not required to use the JDK 1.1 > > implementation; nor are implementations required to be implemented in > > Java" > > > > The XSLT 1.0 specification, which is claimed to be public and > > vendor-neutral, depends on the proprietary, privately owned > > specification for JDK 1.1. > > > > Quite unusual for public specifications. Consequences? > > > > If implementor is not using JDK and/or Java, she *must reimplement* the > > relevant portion of JDK 1.1. > > Yes. And having done so myself, I must say that this is particularly > execrable. I spent days writing Java's format-number nonsense in C (for > decent Python performance), and spent all my time cursing the XSLT WG for > introducing such nonsense into a supposedly language-neutral spec. > > Java's format-number facilities make no sense when you're working with a > language with powerful regex and string processing facilities (Python, > Perl, etc.). I'm not sure what the XSL WG was thinking besides > "Never mind. No one uses anything but Java anyway". > > And that's just the technical aspect of this mess. > > > However, JDK 1.1 specification constitutes > > the intellectual property of Sun Microsystems, Inc., and the "Copyright > > Page for Sun Microsystems, Inc.", which is applied to JDK 1.1 > > specification > > (http://java.sun.com/products/jdk/1.1/docs/relnotes/SMICopyright.html), > > explicitly *does not allow* such reimplementation! > > You know, this never even occurred to me. So it seems that courtesy > the W3C's supposedly open specs, I've fallen into detention at Sun's > pleasure for two offenses: implementing XPointer and XSLT. The fact that > my implementations are open source seems not to help me any. > > > CONCLUSION: The complete implementation of XSLT 1.0 using the platform > > other than Java is not possible without the permission from Sun > > Microsystems, Inc. > > This would seem to be so. Again, this is rot, and something needs be > done about it. Uche, for exactly the same reasons (starting implementing XSLT on top of libxml which is a C only library) I have the same problem. I think the most reasonable way to handle this is to ask the XSL working group to try to fix this in a future revision. There is an XSLT-1.1 revision showing up: http://www.w3.org/TR/xslt11/ I don't see how this can be fixed without breaking some backward compatibility but if noone ask, it sure won't get fixed ! Hence I'm forwarding this message to xsl-editors@w3.org. I was also told that some of the required code had been done for Mozilla too, sorry I don't have a pointer. Daniel -- Daniel Veillard | Red Hat Network http://redhat.com/products/network/ daniel@veillard.com | libxml Gnome XML toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
Received on Saturday, 13 January 2001 13:05:38 UTC