Re: "Debugging" XSLT? Experiences and Methods...
Actually you are talking here not about debugging but about testing and testing strategies. In my experience, the complexity of testing reflects predominantly the architectural complexity (such as modularity, loose or tight coupling, performing only a single task by a given program unit) of a system and not so much the specific programming language used. As for how a programming language affects testing, it can be argued that programs written in a functional language may be generally easier to test because they lack the concept of assignment and mutable variables and therefore are side-effects free. It has been argued that due to this reason it is even easier to *prove the correctness* of a program written in a functional language. In case an application has a good modular structure with single tasks per program unit and loose coupling between modules, it is not too difficult to test in a systematic way. As a rule, the test cases must be as simple as possible and the set of test cases must cover a significant part of the problem scenarios space. As an example, the FXSL library was straightforward to test. Its test cases have been used for testing an XSLT2 processor and its author has commented that using the FXSL test cases helped uncover many bugs in this XSLT processor. Cheers, Dimitre Novatchev On 7/21/05, Karl Koch <TheRanger@xxxxxxx> wrote: > Hello all, > > by now I have done some XSLT scripting mostly with our help and with > background from many many trials and good O'Reilly books :-). I have also > background in a range of programming languages. Coming from thie background > I find it quite difficult, but not impossible, to generate stylesheets. > However, ensuring that they do the rignt thing (on the semanic level) is > quite a headache. Therefore I have at least one or two tests for each > stylesheet (e.g. I have a stylesheet that removes structures which contain > title nodes; than I have another stylesheet that extracts only those who > contain titles and I compare their numbers (number of extraced structures) > regarding the original set. If they add up they do very probable the right > thing - OR THEY ARE BOTH WRONG TO THE SAME DEGREE). I guess you get my > problem here. It is really difficult and depends on the problem. It can also > go very easily completely wrong. If there are small errors it might result > in mistakes in the data which are almost impossible to find (e.g. in very > large data sets of 10000s of XML structures). > > My question here is: How do you verify your stylesheets? > > Is there software or methodlogy which deals with this problem? I think, the > incredibly flexiblity and power of XSLT is at the same time its problem. It > is very difficult to do the right thing. Just thinking and being careful and > checking the code 10 times does not help always... > > Perhaps somebody has references of methodologies or books/papers written > about this problem. Does somebody know good websites that contain some > information about good practise and guidelines of doing good stylesheets? A > discussion is more than welcome and I think it would be right place to have > one.... > > Looking forward to interesting experiences, comments and suggestions. > > Best Regards, > Karl > > -- > GMX DSL = Maximale Leistung zum minimalen Preis! > 2000 MB nur 2,99, Flatrate ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl
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