Re: [xsl] AltovaXML bugs? (and other engines)

Subject: Re: [xsl] AltovaXML bugs? (and other engines)
From: Michael Ludwig <milu71@xxxxxx>
Date: Thu, 2 Apr 2009 00:08:46 +0200
Scott Trenda schrieb am 01.04.2009 um 16:52:40 (-0500):
> Michael,
> 
> I think I get what you're asking. For public specifications (like
> those offered by the W3C), there should be a common flow to
> conformance testing: - run the implementation with the test document
> as the input
> - compare the result against the expected test result
> - repeat for all tests in the package
> 
> And it seems like that could be automated to some extent. Is that
> automated process the "framework" you are alluding to?

Hi Scott,

yes, that's exactly what I meant.

> If so, I'm also curious as to whether or not one exists! The Acid
> tests for CSS take that framework for granted, since it is, after all,
> the browser rendering the test. Where else do you think we could look
> for such a framework, if the W3C doesn't have a publicly available
> one?

Even if the W3C test suite is not publicly available, they might have
a specification, or a standard, on how to write a test, so it would 
probably make sense to adhere to that W3C pattern, as that would allow
easy incorporation of new and interesting tests into their test suite,
if they happen to find any of it interesting, which might not be the
case, after all.

> (I'm coming up short for ideas on who else provides public
> specifications for other companies to implement.)
> 
> It'd be nice if we could find or create an external one (for XSLT 2.0
> engines and some XSLT 1.0 engines, which largely reside as their own
> executable files), and one that runs in the browser (for the XSLT 1.0
> engines provided as part of a browser, like Transformiix and Opera).

Yes. And the browser could probably be scripted by some knowledgeable
JavaScript expert to run the test suite.

Michael Ludwig

Current Thread