[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: second implementation of XSLT 2.0?

Subject: Re: second implementation of XSLT 2.0?
From: Frans Englich <frans.englich@xxxxxxxxx>
Date: Wed, 23 Nov 2005 02:28:55 +0000
xsl 2.0 implementations
On Tuesday 22 November 2005 21:03, DuCharme, Bob (LNG-CHO) wrote:
> Before a W3C Candidate Recommendation advances to Proposed
> Recommendation status, "the Working Group should be able to demonstrate
> two interoperable implementations of each feature."[1] So far, we've got
> Saxon for 2.0, but what else? 

There are advancing XSL-T implementations as mentioned in this thread, but I 
don't see how running a transform or two with each engine answers the 
questions of interest: whether they are interoperable, and that the 
specification is implementable.

Getting solid answers for the interoperability of XQuery/XPath 2.0 engines is 
easier: one just use the XQuery Test Suite. In that case, it doesn't boils 
down to whatever the company's sales department decides to pitch, or what a 
stylesheet or two reveals.

What will be the Working Group's method for testing interoperability? As said, 
I doubt a couple of stylesheets will give an answer which reflects 
conformance/interoperability. XSL-T 2.0 is large.

If time wasn't a constraint[1], I would from the Working Group's perspective 
first focus on getting a test suite done in order to be able to properly test 
implementations, as well as to get a thorough review of the spec.

I'm curious, what are the estimations on finding two interoperable 

Both Altova and Gestalt are new kids on the block(I don't think Gestalt is 
feature complete, no?). What is more exactly the status quo of Oracle's 
processor? What implementations is there otherwise? 

I am working on an XPath/XSL-T 2.0 implementation: KXPath and KXSL-T. The 
XPath part is close to feature complete, but XSL-T is essentially not yet 
started, so there's nothing to count on from my side.[2]

By the way, wasn't it somwhere discussed to raise the requirement to three 



Personally, I don't see why it would matter if the spec went into 
recommendation a half/quarter of a year later. The spec won't change 
significantly because it is released later; it's thus not an obstacle for 
users nor implementors, from what I can tell. The advantage is that more 
editorial issues can be found, implementors can catch up, and it all shaken 
into place.

It wouldn't surprise me if XSL-T would in my case be relatively faster to 
implement than XPath due to that the XSL-T implementation will use a lot of 
the KXPath code, in terms of framework code, type system, intermediate 
representation(IR), and others in the similar vein.

Current Thread


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.