Re: second implementation of XSLT 2.0?
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." 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, 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. 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.
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format