This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
format-number() causing problems to non-java implementators
- To: "xsl-list at lists dot mulberrytech dot com" <xsl-list at lists dot mulberrytech dot com>
- Subject: [xsl] format-number() causing problems to non-java implementators
- From: Miloslav Nic <nicmila at idoox dot com>
- Date: Tue, 16 Jan 2001 07:01:26 +0100
- Reply-To: xsl-list at lists dot mulberrytech dot com
Hello.
Currently there is a rather heated debate on xml-dev about problems with
standards and private technologies. You will
find the whole archive at:
http://lists.xml.org/archives/xml-dev/200101/threads.html
threads:
XPointer and Sun patent
Place under sun (was: XPointer and Sun patent)
Some contributions are rather interesting, I found the attached one
especially intriguing.
While the legal problems are definitively serious it is something I
would need a tutorial to understand ;) . But there seem to
be a serious technical (and not necessary) problems in the spec as well.
I would definitively like something more general and better documented
than format-number in the XSLT 1.1 and as it causes
problems to many implementators, I suppose this can be a good
opportunity to make format-number depreciated function in 1.1 and remove
it from 2.0.
BTW: Are there more functions causing problems for non Java
implementators?
Attached mail:
Subject: Re: Place under sun (was: XPointer and Sun patent)
Date: Sat, 13 Jan 2001 19:05:33 +0100
From: Daniel Veillard <Daniel.Veillard@imag.fr>
[ 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/
--
******************************************
<firstName> Miloslav </firstName>
<surname> Nic </surname>
<mail> nicmila@idoox.com </mail>
<support> http://www.zvon.org </support>
<zvonMailingList>
http://www.zvon.org/index.php?nav_id=4
</zvonMailingList>
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list