Re: [xsl] second implementation of XSLT 2.0?

Subject: Re: [xsl] second implementation of XSLT 2.0?
From: Frans Englich <frans.englich@xxxxxxxxx>
Date: Wed, 23 Nov 2005 02:28:55 +0000
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 
implementations? 

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


Cheers,

		Frans

1.
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.

2.
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