Re: My favourite XSLT enhancement requests

[Alexey Gokhberg <alexei@xxxxxxxxxx>]

Steve Muench wrote:
> 
> > XSLT specification provides the adequate mechanism for this -
> > extensions. Of course, currently there is no standard mechanism for
> > communication between XSLT stylesheets and scripts, but, since we talk
> > about future development why not to concentrate efforts on the
> > specification of such mechanism rather than on the creation of the
> > particular additional XSLT features?
> 
> Alexey,
> 
> Please see:
> 
>   http://www.w3.org/TR/xslt11req.html
> 
> This is the first working draft of the requirements for
> XSLT 1.1, wherein standardizing the extension function
> mechanism for ECMAScript and Java (and allowing for
> other languages) is being worked on by the XSL Working Group ...

Thanks, I had seen this document before. 

It contains a first "draft* for *requirements*, not ready-to-use
specifications. And, from my point of view, there is a lot to discuss
about this proposal.

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? 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?

>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 way to specify abstract (language-independent) interfaces between
stylesheets and code implementing extensions must be provided
- the interface specification must be simple and intuitive (stylesheet
authors SHOULD NOT be programmers, therefore something like OMG IDL
probably would not work)
- 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

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.

Regards,

Alexey


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