Place under sun (was: XPointer and Sun patent)

[Alexey Gokhberg <alexei@bluewin.ch>]

Dear colleagues

Unfortunately, the XPointer case recently discussed on this list is not
an exception. Let us consider the following facts:

FACT 1: 
-------

"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. 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!

CONCLUSION: The complete implementation of XSLT 1.0 using the platform
other than Java is not possible without the permission from Sun
Microsystems, Inc.

FACT 2:
-------

"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.

The principal goal of specifications like this is achieveing
interoperability between software components developed by different
vendors. In reality, however, interoperability can be achieved only for
components written in one general-purpose language - Java, since
abstract interface definitions are practically useless without the
appropriate language-dependent bindings.

Why W3C does not follow the common practice followed by other standard
bodies, which provide bindings for various *standard* languages?

CONCLUSION: The (public) DOM specification promotes (privately-owned)
Java programming language. Developers using other programming languages
get less benefits than Java developers - due to the nature of the
specification, not because those languages are inferior to Java.

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.

CONCLUSION: The (public) XSLT 1.1 specification promotes
(privately-owned) Java programming language. Developers using other
programming languages get less benefits than Java developers - due to
the nature of the specification, not because those languages are
inferior to Java.

--------------------

These facts are taken from the relatively small area I am familiar with.
I am wondering, how many traps like those described here are hidden in
the entire collection of W3C documents?


Kind regards,

Alexey Gokhberg