Re: XPath "//", speed, and Saxon
> In some ways, the old-fashioned 'match="*"' template rule that emits a > message or outputs the element name in red for any element that isn't > handled elsewhere is still useful even when you have schema awareness. > or a coverage tool (non-existent, AFAIK) that tells you whether your > stylesheet can handle everything in a schema would also still be useful. wouldn't the match="*" template kind of skew your coverage checking? :) The other benefit of schema awareness is when the schema changes, you just need to modify your transform accordingly (hopefully with lots of underlining and help from the IDE) and you're ready to go. With unit tests, you'd have to go through and update the tests based on that change. I'm not saying choose between them (unit tests are ideal for testing functions) just that for XSLT the "fashionable" way of development shouldn't be unit tests and coverage tools, it should be schema based. For example, you have a template which should output: <foo a="b" b="c"><bar/></foo> Why go to all the effort of setting up a unit test, along with a suitable way of comparing the expected and actual fragments, when you could just add an "as" attribute to the template: <xsl:template match="whatever" as="element(foo)"> Then if the template changes or the schema changes and that template generates the wrong output, you get a message, line number etc and if you're lucky a big red line under that template in the IDE. Reducing faults through schema-awareness is the best approach and, if you like, writing input and output schemas really is test-first development. You're still comparing expected with actual output, just in a different way. -- Andrew Welch http://andrewjwelch.com Kernow: http://kernowforsaxon.sf.net/
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