OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Place under sun (was: XPointer and Sun patent)

[ 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.


 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 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 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/