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]

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



>BTW: Are there more functions causing problems for non Java
>implementators?
>

From my C++ implementation, format-number() was the big pain until I
discovered that the IBM ICU library contains the functionality needed.
Without this library I would really be stuck. I think this is how the Apache
C++ XSLT processor also deals with the problem. I don't believe there are
any other specification issues for C++ implementations.

I find the move to using more extension code to be more worrying. There is
no way I want to implement a C++ XSL processor only to have it call a JVM to
execute user defined code. And I am sure we don't want to have to write all
our extension functions in multiple languages to stay portable. Jeni's
recent excellent proposal that you can define extension functions in XSLT
appears to me a much saner solution for creating portable XSLT and avoiding
inappropriate language dependencies.

Kev.


 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]