[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

format-number() causing problems to non-java implement

Subject: format-number() causing problems to non-java implementators
From: Miloslav Nic <nicmila@xxxxxxxxx>
Date: Tue, 16 Jan 2001 07:01:26 +0100
java format
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@xxxxxxx>


[ Cc'ed to xsl-editors@xxxxxx, 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@xxxxxxx

 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@xxxxxxxxxxxx  | 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@xxxxxxxxx    </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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.