[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Verifying large XSL transform output
Matthew, I think that would work for a simple case, where content moves 1:1 from source to destination. In the case I have, the source XML is some rather horribly designed stuff thats mimicking a relational data model and the target is a human oriented DSL where one clause may contain information from multiple source elements and there are multiple cases where a value from the source is transformed into something else entirely in the destination or disappears completely (redundant information in the source that can be reconstructed from context in the DSL). Sorting the paths loses ordering, which means you can't check that significant information encoded as ordering is preserved. A specialised XML comparison is not hard to do though, a bit of recursion, a bit of sorting where ordering is lost, and some bits of "if we are here, ignore this missing bit I don't really care about". So if you have 1:1 input to output, no content transformation, no content merging, and no redundant source data then you are fine. I have a suspicion that things could get complicated fast. Greg On Thu, Feb 13, 2014 at 5:43 AM, Matthew Stoeffler <Matthew.Stoeffler@xxxxxxxxxx> wrote: > 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.
|
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
|