[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: Greg Hunt <greg@xxxxxxxxxxxxxx>
Date: Fri, 14 Feb 2014 08:48:33 +1100

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.


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.

Current Thread