Re: My favourite XSLT enhancement requests

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

It's a requirements document so it of course does not propose
the implementation of the requirements but the requirement is
that it be *possible* to write a stylesheet requiring extension
functions that can be portable across XSLT processor implementations.

Right now, the situation is as follows:

  (1) The extension function mechanism is optional in XSLT 1.0.

      (Lightweight implementations of XSLT in a palm browser might
       rightfully decide that implementing extension functions is
       not a feature that they require, and the optionality of
       the extension function mechanism supports this implementation)

  (2) You in general cannot write stylesheets with extension functions 
      that are portable between any two vendors XSLT engines.

The working group is trying to address portability issues raised
by users on the XSL-List about the two most popular languages
for extension function implementations which existing XSLT processors
implement, making (2) above possible without changing (1) above.

| In particular, how the XSLT stylesheet that contains an embedded Java code
| should be ported to the XSLT processor that does not (and SHOULD NOT be
| required) to support Java?

If XSLT 1.1 were to provide an implementation of the requirements
above, this would mean the following:

  -> A stylesheet that requires extension functions using
     one of the specified languages can be run on any
     XSLT 1.1-compliant processor that supports the same 
     language binding for extension functions.

| From my point of view, something quite opposite is needed to implement
| truly portable extensions. In particular:
| 
| - the stylesheet must not contain any language-specific code (this rules
| out both inline implementations of extension functions and access to
| language-specific data types)

The requirements do not preclude the situation where all language-specific
code is specified outside the stylesheet itself. In fact is says it
MUST be possible to specify the extension function implementation outside.
This could be your preferred way of working.

| - the way to specify abstract (language-independent) interfaces between
| stylesheets and code implementing extensions must be provided

This would done in the spirit of DOM, SVG, and other specs. By specifying
the interface in IDL, and providing language bindings for this generic
interface (initially) in Java and ECMAScript, allowing for other language
bindings in the future.

| - the interface specification must be simple and intuitive (stylesheet
| authors SHOULD NOT be programmers, therefore something like OMG IDL
| probably would not work)

There is no requirement that stylesheet authors necessarily be the
same person that authors extension function implementations. In fact,
the requirements are designed to allow developers more comfortable
with programming to implement the extension functions and provide
the extension functions as a library to be used by stylesheet authors.
The requirement is that they must work like built-in functions
so that it is possible for stylesheet authors to use extension 
functions in the same, natural way as built-in functions. 

| - the interface specification should be ...mmm... object-oriented (the
| stylesheet author should be able to access properties and methods of the
| abstract objects implemened elsewhere)
| - the bindings of the abstract interface to the particular languages
| should be defined, however, these bindings should be hidden from the
| stylesheet authors

Not all possible implementation languages that might want to be
used for extension functions are object-oriented languages. So
using IDL-interface-based contracts are a way that have proven 
successful for other W3C specifications to communicate the
abstract requirements so that consistent language bindings can
be developed in any language.

| My original proposal is offering a tool which might be inferior to "all
| of best known XSLT engines", but already supports the portable approach
| to XSLT extensions and could be used *now* to test various ideas about
| XSLT extensibility.

As with all feedback from the XSL-List community,
your implementation experience in making such a tool
available to evaluate might provide valuable 
input to the XSL working group.

______________________________________________________________
Steve Muench, Lead XML Evangelist & Consulting Product Manager
BC4J & XSQL Servlet Development Teams, Oracle Rep to XSL WG
Author "Building Oracle XML Applications", O'Reilly
http://www.oreilly.com/catalog/orxmlapp/

Received on Friday, 15 September 2000 17:43:05 UTC