IMPORTANT:
this is not a Support Forum! Experienced users might answer from time to time questions posted here. If you need a professional and reliable answer, or if you want to report a bug, please contact Altova Support instead.

The "position" value in DD reports Options · View
cashpt
Posted: Friday, February 1, 2008 11:09:31 PM
Rank: Newbie

Joined: 2/1/2008
Posts: 4
Location: Irving, TX
We've been trying to use the report generated by DiffDog ("Export Differences") to identify changes between 2 versions of the same document. The idea was to process the DD report, then create an XSLT (or maybe a Perl program) using the XPATH statements given in the report to extract the changed elements.

These changed elements would then be handed off to the translators, as only new or changed content has to be translated. After translation, the mechanism would be run in reverse to substitute the new, translated text for the original text that was identified as having changed.

The problem is that the "position" value in the report doesn't mean what I thought it did. I'm not sure if this is a bug, or simply the result of my failure to understand the fine points of XPATH.

I've figured out that when DD gives a position value n, then this does not mean that the changed element is the nth sibling element of that type. For example, lets say we have XML source that looks like this:

<ol type="arabic">
<li>one</li>
<li>two</li>
</ol>

DiffDog would report the parent xpath of the second list item as "/ol", and give its position as 3. Why 3? Well, that had me stumped for some time (our documents are a bit more complex than my example). I expected the the second li child would be reported as the second child...as having position "2", in other words. Apparently, DD is doggedly counting nodes, and not elements. If you do that, then I suppose the type attribute of the ol element is the first node that's encountered after the start of the ol element.

While this might have made sense to whoever wrote DD, I don't find it useful. I'm still scratching my head over how I can reliably process the DD output to programmatically construct XPATHs that will identify changed elements in complex XML docs. To go back to my example, I had hoped I could simply use /ul/li[n], where n is drawn from the position value. But no such luck.

Please tell me this is really a DiffDog bug.
cashpt
Posted: Friday, March 14, 2008 2:56:05 PM
Rank: Newbie

Joined: 2/1/2008
Posts: 4
Location: Irving, TX
Uhh....sorry. I did eventually figure this out. Attributes are nodes. *beats self on head with mallet*
Users browsing this topic
guest

Forum Jump
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

Use of the Altova User Forum(s) is governed by the Altova Terms of Use.