Re: [xsl] extensions and XSLT 2.0

[Frédéric Laurent <fl@xxxxxxxxxxxxx>]

On Friday 16 May 2003 17:31, Michael Kay wrote:
> > I've got some questions about element/instruction extensions in the
> > specification of XSLT 2.0.
> > The definition concerning the data mapping between XPath types and
> > java/ecmascript... types, described in the version 1.1 has
> > disappeared.
>
> The decision to abandon the attempt to define language bindings for
> extension functions was made a long time ago, and documented in the XSLT
> 2.0 requirements. There were a number of reasons for the decision. The
> fact that the XSLT 1.1 draft supported Java and ECMAScript, and no other
> languages, was very sensitive politically, both with vendors and with
> users. If you look in the archives of this list you will find the
> evidence of the user side of this, though it was probably the vendor
> side that influenced the working group to make the decision. Another
> factor was that it was becoming clear that XSLT 2.0 would have a much
> richer type system, and that bindings between Java types and XML Schema
> types were not a local matter for the XSL WG to define on its own.
>
> The decision at the time was that standardized language bindings, e.g.
> for Java, would be useful, but they should not be done within W3C and
> should not be part of the XSLT specification. Eventually I hope that
> they might become part of JAXP.

Thanks for your response, this is the confirmation of my reading
of the archives of the list and other articles.

Then I've got 1 concrete question (more in fact, but let's start with it) :

I write an extension element in java with the saxon processor by
implementing the net.sf.saxon.style.ExtensionElementFactory. It works,
and I'm very happy. But then, I have to change the implementation of xslt,
and move to xalan (or any other java processor). 
I've got a problem, haven't I ?
Saxon uses its own interface, and xalan too... So I've got to rewrite
my extension according to the xalan interface.

I thought that XSLT 1.1 would provide independant interfaces (in the same
way that DOM does with the org.w3c.dom.* package) in order to write
portable code. Wouldn't it be more simple and safe for user to have such
a definition ?

The problem is identical if I choose to write my extension element in python
or C... 

Am I wrong ?


-- 
Frédéric Laurent
http://www.opikanoba.org

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