Re: My favourite XSLT enhancement requests

[Alexey Gokhberg <alexei@xxxxxxxxxx>]

Hello, Steve

Let me put it this way (Q>-question, A>-answer).

Q> | For instance, section 3 of this document called "Requirements for
Q> | *Portable* Extension Function Implemenations" requests, in
particular:
Q> |
Q> | - "... Extension function implementations MUST be allowed both
inline as
Q> | well as externally  ..."
Q> | - "...It SHOULD be possible to return an object of any
host-language
Q> | type from the extension function ..."
Q> | - "...It SHOULD be possible to pass an object of any host-language
type
Q> | to an extension function ..."
Q> |
Q> | but, on the other hand,
Q> |
Q> | - "... A processor SHOULD NOT be required to implement the portable
Q> | extension function binding for any particular language ..."
Q> |
Q> | Does it really propose *portable* extension implementations?
Q> 

A>
A> ... the requirement is
A> that it be *possible* to write a stylesheet requiring extension
A> functions that can be portable across XSLT processor implementations.
A> 
A> .........
A>
A> The working group is trying to address portability issues raised
A> by users on the XSL-List about the two most popular languages
A> for extension function implementations which existing XSLT processors
A> implement ...
A>
 
Q>
Q> | In particular, how the XSLT stylesheet that contains an embedded
Java code
Q> | should be ported to the XSLT processor that does not (and SHOULD
NOT be
Q> | required) to support Java?
Q> 

A>
A> If XSLT 1.1 were to provide an implementation of the requirements
A> above, this would mean the following:
A> 
A>   -> A stylesheet that requires extension functions using
A>      one of the specified languages can be run on any
A>      XSLT 1.1-compliant processor that supports the same
A>      language binding for extension functions.
A> 

Now I got the following questions:
----------------------------------

1. WHAT IS INDEED A PORTABILITY?

Let's assume that we have to consider the following platorms for
extension development:

    - Java
    - ECMAScript (JavaScript)
    - C
    - C++ 
    - ActiveX (COM)
    - CORBA

The last two platforms are not programming languages proper, but are
very likely to be used for extension development in the future. Please
note, that first 5 platforms mentioned are already used in various XSLT
implementations that are available now.

Let's assume that we accept principles proposed by W3C (cited and
commented above). According to these principles, there might exist the
following classes of XSLT processors with regards to the bindings
supported:

1. Processors that do not support extensions
2. Processors that support Java only
3. Processors that support ECMAScript only
4. Processors that support C only
5. Processors that support C++ only
6. Processors that support Java and ECMAScript only
7. Processors that support Java and C only (why not?)
    ............
64. Processors that support bindings for all 6 platforms

Total of 2**6 = 64 different classes, and the number of classes will
grow exponentially if we would consider more platforms (2 power N, where
N - number of platforms supported).

Stylesheets with extensions will be portable only among processors that
belong to the same class. In the example above we might have up to 64
incompatible XSLT dialects! Is this a portability?


2. IS IT REALLY FOR ALL XSLT DEVELOPERS ...

I cite again:

"The working group is trying to address portability issues raised ...
about the two most popular languages
for extension function implementations which existing XSLT processors
implement ..."

How implementors that are using "less popular languages" should proceed?
How the popularity was measured? Is there any statistics available? Or
there is some central authority that decides which language should be
treated as popular? And who can predict what will become popular in one
year?

Were *all* existing XSLT processors considered? Or only those developed
by W3C members?


3. ... OR IT IS FOR JAVA FREAKS ONLY?

At the first step W3C plans to provide support for Java and ECMAScript
only. I am afraid that there might be no second step (with regards to
the language support) and we might never see binding specifications for
other languages. (By the way: which language bindings are currently
supported by W3C DOM specification?)

Why not to follow the commonly used practice: define the ABSTRACT,
PLATFORM-INDEPENDENT model first, then specify bindings for all
platforms needed by the user community? 

Why not to follow the pattern set by major standartization bodies, which
normaly provide bindings for the variety of languages and platforms?
Consider, for instance, OMG CORBA spec: there exist IDL bindings for
Ada, C, C++, COBOL, Java, Smalltalk as well as mapping to COM.

Why XSLT implementors that are using Java should enjoy more benefits?
Why users that prefer C++ based implementations should suffer from the
lack of standartization?


Thank you for your attention.

Kind regards,

Alexey


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list