[XSL-LIST Mailing List Archive Home]
[By Thread]
[By Date]
Re: [xsl] Verifying large XSL transform output
Subject: Re: [xsl] Verifying large XSL transform output From: Matthew Stoeffler <Matthew.Stoeffler@xxxxxxxxxx> Date: Wed, 12 Feb 2014 13:43:02 -0500 |
Greg. Thought occurs to me about a possible short cut to this. What if your main transform added a @srcPath to each new element node you generated, where the attribute contains the xpath location of the node that it came from. Your transform setup just has a identify script that follows that strips out the attributes, but also writes all of them out as text, saving the paths in a text file. You then run the xmlstarlet el command on the original source to a text file. Sort both path files and compare. Would that work? It sounds more generalized for multiple projects. I haven't attempted it yet, so it might be more work than I think, but hopefully less work than writing two full transforms. I mean, my transform scripts for the current project are several thousand lines combined. m./ On Feb 11, 2014, at 3:29 PM, Greg Hunt wrote: Another vote here for round tripping and comparing the result with the source using a specifically built comparison tool. I have a project under way right now doing that. Its a non-trivial amount of work, but you have to test somehow, and I don't know how you would write and execute comprehensive test cases otherwise. The comparison tool will be a lot simpler than the transformations, so it is easy to test manually. This approach has the advantage that the entire body of input XML can be the test data, leaving no corner cases uncovered.
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: [xsl] Verifying large XSL trans, Greg Hunt | Thread | Re: [xsl] Verifying large XSL trans, Greg Hunt |
Re: [xsl] Verifying large XSL trans, Paul Tyson | Date | [xsl] Ignoring ambiguous matches, Ihe Onwuka |
Month |