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.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--