I forgot to mention that I’m also a member of the project for Jeni Tennison’s XSpec project at http://xspec.googlecode.com/, which is a Behavior Driven Development (BDD) framework for XSLT.Â Mind you, the few changes that I have made would only count as gilding the lily.
Some days you may be the best XSLT exponent on the planet; other days you may make a simple mistake and not realise it.
Particularly when you are writing tests after someone else wrote the stylesheet, if you find yourself on a roll with all your new tests coming up green first time, it can be useful to occasionally break a working test a little so that it’s bound to fail. Continue reading “Break your own tests”
Juxy (http://juxy.tigris.org/), by Pavel Sher, is a library for unit testing XSLT stylesheets from Java. After a long time spent threatening to do so, I finally contributed an XML format for Juxy tests.
I’ve been riding my hobby horse for a while about the usefulness, nay necessity, of using more than XSLT when testing XSLT (and I’ll be back in that saddle again at XML Prague). Juxy fits that bill, since it’s in Java, but it always seems to me that writing tests in Java is more than many XSLT practitioners would want to do. So I wrote a stylesheet to generate Java from XML descriptions of the tests. Continue reading “Juxy”
I used to think that the open source xs3p schema documentation generator stylesheet from the now-defunct http://titanium.dstc.edu.au/ was the secret sauce behind the remarkably similar graphical XML schema representations of both <oXygen/> and XML Spy.Â I was wrong: a modified version of xs3p is bundled with <oXygen/> and is used when generating printed documentation, and xs3p may still be included in XML Spy (though it’s unlikely since its currently not listed on their third-party licenses page), but even in its titanium days, it didn’t do any graphical representations of a schema.
Does anybody know of an open source toolkit that can produce that sort of graphical representation?
Why should you prefer an XSLT unit testing framework that uses more that just XSLT? Two reasons:
xsl:message and multiple output documents. Continue reading “Why use more that XSLT for testing XSLT?”
I have been selected to present my “Testing XSLT” tutorial at XTech 2008 in Dublin in May.
Slides for my two XML 2007 training courses are now available on the Menteith Consulting website:
I recently tripped over a difference between XSLT 1.0 and XSLT 2.0 that is not currently listed in Appendix J, Changes from XSLT 1.0 (Non-Normative), of the XSLT 2.0 spec.
In XSLT 1.0, when @lang is not specified on xsl:sort, its value should be determined from the system environment (my emphasis). In practice, it seems that most xsl:sort in XSLT 1.0 stylesheets are written without a @lang and people are used to XSLT processors “doing the right thing” when sorting text.
In XSLT 2.0, “if none of the collation, lang or case-order attributes is present, the collation is chosen in an implementation-defined way.” This is more honest than XSLT 1.0’s “should” (as was pointed out to me by Liam Quin), since “implementation-defined” really does have to be defined. However, that does mean the processor is not required to consider language when @lang is omitted.
Despite the three paragraphs written so far, I believe the XSLT 2.0 behaviour is adequate, and if you’re writing an XSLT 2.0 stylesheet, you’re better off specifying a collation (implementation-specific as it unfortunately currently must be) than either omitting attributes or specifying a single language and trusting that your processor both agrees with you on the minutiae of sorting punctuation, etc., and gets right the sorting of the other languages that you weren’t able to specify.
However, where I tripped up (minor as it was) was when using an XSLT 1.0 stylesheet with an XSLT 2.0 processor. I was using an XSLT 2.0 processor because I’d added an XSLT 2.0 stylesheet to an existing sequence of XSLT 1.0 stylesheets (since the task, and the new stylesheet, was made much simpler with regex). The new stylesheet sequence had worked correctly in my tests, but results were in an unexpected order when my client tried the sequence on some new input, and could I please fix it?
Everybody’s assumption was that it was a problem with the new stylesheet, but happily it checked out okay. The cause was a long-forgotten xsl:sort in my client’s existing stylesheets:
<xsl:sort select=”@name” order=”ascending” data-type=”text”/>
The previous XSLT 1.0 processor had been sorting according to the implicit language setting, and the XSLT 2.0 processor was sorting on Unicode codepoint, just as it said in the release notes. This hadn’t shown up in my tests because my data had been all in lowercase (which was the norm).
The lessons are for stylesheet writers to specify @lang if there’s any possibility that their XSLT 1.0 stylesheet will be run by an XSLT 2.0 processor and for me to use more complex test data with my client’s system, which I am doing.