RE: AltovaXML bugs? (and other engines)

Unfortunately the W3C test suite is available to members only, largely
because there is not complete traceability of the origin of all the tests.
It tests many corners of the spec that real user code rarely visits, but on
the other hand it's also true that the tests are mostly fairly simple, so it
doesn't tend to expose combinatorial problems. It also has relatively weak
coverage of areas where the results are to a greater or lesser degree
implementation-defined (for example sort order).

Michael Kay
http://www.saxonica.com/ 

> -----Original Message-----
> From: Scott Trenda [mailto:Scott.Trenda@xxxxxxxx] 
> Sent: 01 April 2009 02:38
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: RE:  AltovaXML bugs? (and other engines)
> 
> Just a thought (maybe someone's done it already)... is there 
> some sort of Acid test for XSLT processors? I think there are 
> conformance test packages available from W3C, but it's 
> usually the experienced XSLT developers who know how best to 
> break an XSLT engine. It'd be nice to have such a test for 
> both XSLT 1.0 and XSLT 2.0, since we could know exactly how 
> and where the different XSLT engines fail.
> 
> I'm guessing Michael Kay would know the best place to start here. :)
> 
> ~ Scott
> 
> -----Original Message-----
> From: Philip Vallone [mailto:philip.vallone@xxxxxxxxxxx]
> Sent: Tuesday, March 31, 2009 8:25 PM
> To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> Subject: Re:  AltovaXML bugs? (and other engines)
> 
> Hi,
> 
> I will report this to Altova tomorrow via their ticket 
> system. They are continually updating xmlspy, but I have not 
> seen a running list. I would be interested in seeing dif list 
> also. xmlspy is a great editor and has a decent xslt 
> processor. Saxon, by far is the best. It's fast and reliable. 
> Saxonica (Michael Kay) is very good at providing the very 
> best xslt 2.0 processor.
> 
> Phil
> 
> 
> 
> 
> On Mar 31, 2009, at 9:15 PM, Scott Trenda wrote:
> 
> > In response to this... we're using AltovaXML at my work, since its 
> > license is very business-friendly and it doesn't require a managed- 
> > code base (Java or .NET) to run. However, I've noticed that when 
> > compared to Saxon, it gives different output in some 
> places, and for 
> > the few times I've looked into it, the error is within AltovaXML.
> > (Not to mention it's slow compared to Saxon.)
> >
> > Is there a list somewhere of known issues within 
> AltovaXML's XSLT 2.0 
> > engine? Although we're not using it very often at my work, it'd be 
> > nice to know what pitfalls to avoid.
> >
> > And while I'm asking, does anyone know of a similar list for 
> > Transformiix (Firefox's XSLT engine) and Opera's XSLT 
> engine? I know 
> > I've asked for a standalone of Opera's engine before, but this time 
> > I'd just like to know what these two don't support. I know 
> > Transformiix doesn't recognize the namespace:: axis, but 
> that's about 
> > it.
> >
> > ~ Scott
> >
> >
> > -----Original Message-----
> > From: Philip Vallone [mailto:philip.vallone@xxxxxxxxxxx]
> > Sent: Tuesday, March 31, 2009 7:03 PM
> > To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
> > Subject: Re:  Counting with xsl:key
> >
> > Thanks... works perfect. Actually xmlSPY throws an error if 
> the select 
> > statement is in the <xsl:number>
> >
> > <xsl:number level="any" count="figure[not(@inline='true')]"
> > select="key('fig-key', @href)" />
> >
> > Saxon runs it as expected... Saxon rocks
> >
> > Thanks again,
> >
> > Phil