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(_dot_)Stoeffler(_at_)ithaka(_dot_)org> 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.
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail:
<mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--