Re: Place under sun (was: XPointer and Sun patent)

[Uche Ogbuji <uche.ogbuji@fourthought.com>]

> "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@fourthought.com               +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