This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]