[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Place under sun (was: XPointer and Sun patent)
> "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. > "Document Object Model (DOM) Level 2 Core Specification Version 1.0. W3C > Recommendation 13 November 2000" (http://www.w3.org/TR/DOM-Level-2-Core) > specifies the collection of abstract DOM interfaces, as well as bindings > for few languages. > > Bindings for the following languages are specified: > > * Java > * ECMAScript > > Therefore, the only general purpose programming language supported by > this specification is privately owned (and, strictly speaking, > non-standard) Java. Plenty of other languages, recognized by > international standard authorities (and widely used by the world > community), like Ada, C, C++, Cobol, etc., are not supported. I'm not sure I see any evil here. On the Python/XML SIG we've hashed out a Python binding and I have no sense that it would be rejected if we sent it to the W3C for status. At least the DOM WG used IDL, a language-neutral approach to specifying the API. I have seen many specs evolve through the Java lens and they tend to get very badly distorted. > FACT 3: > ------- > > "XSL Transformations (XSLT) Version 1.1. W3C Working Draft 12 December > 2000", section "14.4 Defining Extension Functions" > (http://www.w3.org/TR/xslt11/#define-extension-functions) defines > standard bindings for the following programming languages: > > * ECMAScript (public specification [see ECMA-262]) > * JavaScript (privately-owned specification) > * Java (privately-owned specification) > > Again, the only general purpose programming language, for which bindings > are specified, is Java. Bindings for other (standard, widely used, etc.) > languages are not covered by this specification and are, therefore, > non-standard. > > Consequences? > > XSLT processors, implemented in the language other than Java, cannot > provide users with the same benefits as Java-based implementations. For > example, XSLT processors implemented in C++ by different vendors (yes, > there are several available) cannot provide the vendor-independent > method for accessing arbitrary C++ classes, unless vendors using C++ > will agree on some vendor-independent specification (could be a good > idea, indead). > This means, in fact, that in the future truly extensible XSLT processors > could be implemented only in Java. I was about to take up this war on the XSL list. Some things in the XSLT 1.1 draft make my hair stand verily on end. -- Uche Ogbuji Principal Consultant uche.ogbuji@f... +1 303 583 9900 x 101 Fourthought, Inc. http://Fourthought.com 4735 East Walnut St, Ste. C, Boulder, CO 80301-2537, USA Software-engineering, knowledge-management, XML, CORBA, Linux, Python
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|