[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Place under sun (was: XPointer and Sun patent)
- From: Daniel Veillard <Daniel.Veillard@imag.fr>
- To: Uche Ogbuji <email@example.com>, firstname.lastname@example.org
- Date: Sat, 13 Jan 2001 19:05:33 +0100
[ Cc'ed to email@example.com, 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.
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:
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 firstname.lastname@example.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 Veillard | Red Hat Network http://redhat.com/products/network/
email@example.com | libxml Gnome XML toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/