xsl-list
[Top] [All Lists]

Re: extensions and XSLT 2.0

2003-05-16 09:16:46
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



<Prev in Thread] Current Thread [Next in Thread>