Subject: Re: [xsl] XPath "//", speed, and Saxon From: Tony Graham <Tony.Graham@xxxxxxxxxxxxxxxxxxxxxx> Date: Mon, 03 Nov 2008 17:27:05 +0000 |
On Mon, Nov 03 2008 16:07:35 +0000, andrew.j.welch@xxxxxxxxx wrote: >> 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? :) Of course. You'd want a list of what is only matched by built-in or wildcard templates. > 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. What does the IDE show for the one added optional attribute among twenty added required elements? > 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. I'm not saying that you should choose between them either. Leaving aside the two questions of whether or not schema awareness is always an option (e.g., when you are using translets) and of exactly how much automated checking is "fashionable" for XSLT to begin with, neither schema awareness nor unit testing is a panacea. Schema awareness type checking is good for saving you from yourself (and I do make liberal use of 'as="..."' to save me from myself when writing XSLT 2.0), but you can still go wrong. Unit tests are only as good as the effort you put into creating them and, as you note, keeping them up to date. I recently wrote some test cases for an extension to a FO processor: the test cases all initially passed the area tree checks because I hadn't added assertions about the extension I was testing; they passed again when I added assertions based on the current output; and they all failed when I changed where the extra FOs were added to the area tree, even though the PDF output was visually identical (which I was testing a different way). Even at its best, unit testing won't catch everything [1] (it won't come close) any more than type checking will. A combination of tests/checks/reviews will catch more than will using one method alone. > 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. And if the schema doesn't extend to patterns or enumerations for those attribute values and your brain short-circuits and you produce: <foo a="c" b="b"><bar/></foo> ? > 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. I'm all for testing it in as many ways as possible for the least effort and the maximum confidence in the result. So using schema awareness when it is an option is perfectly fine by me. Regards, Tony Graham Tony.Graham@xxxxxxxxxxxxxxxxxxxxxx Director W3C XSL FO SG Invited Expert Menteith Consulting Ltd XML, XSL and XSLT consulting, programming and training Registered Office: 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland Registered in Ireland - No. 428599 http://www.menteithconsulting.com -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- -- xmlroff XSL Formatter http://xmlroff.org xslide Emacs mode http://www.menteith.com/wiki/xslide Unicode: A Primer urn:isbn:0-7645-4625-2 [1] https://www.menteithconsulting.com/wiki/XTech2007/MyStylesheetRunsBut#EffectivenessofUnitTesting
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
RE: [xsl] XPath "//", speed, and Sa, Michael Kay | Thread | Re: [xsl] XPath "//", speed, and Sa, Andrew Welch |
Re: [xsl] Qualified variable names, G. Ken Holman | Date | [xsl] XSL help, Caroline Umali |
Month |