| cashpt |
| Newbie |
|
| Irving, TX |
|
|
| None Specified |
|
| Friday, February 1, 2008 |
| Monday, May 5, 2008 2:47:00 PM |
4
[0.02% of all post / 0.00 posts per day] |
|
I also have a "wish list" for DiffDog:
1. Allow comparing attribute values when "ignore text" is turned on.
Right now, DiffDog ignores attribute values when "ignore text" is selected as an option for the compare. We would find it enormously helpful to have the option to compare attribute values.
We are having to compare translated XML files against the English original, hence "ignore text". However, DiffDog often cannot accurately identify structural changes (which is what we are looking for); for example, if a list item was added to a list, DiffDog assumes it's the first one, even though it's not. If DiffDog could be told to look at attribute values, then the accuracy of the comparison would be greatly improved, because most of our elements have an ID attribute.
It would be helpful to have a global option "consider attribute values"; however, the optimal solution would be to support a "white list" of attributes for values that should be considered in the comparison.
2. The handling of indents and white spaces in the comparison pane is somewhat unsatisfactory at this point. As one poster has commented, whether to indent the XML text should be an option that--once set--should be "remembered" by DiffDog between sessions.
Also, there's a more serious problem that results from choosing to "pretty print" (pretty display?)--DiffDog actually writes the white space from the indenting to the file if changes are saved. Thus, we get XML files with a bunch of extra white space that chokes some other applications we're using. Someone might very well want the option to preserve the indenting permanently; I just want to look at the XML in a way that helps make sense of it while I'm comparing files, I don't want the white space preserved.
|
|
Uhh....sorry. I did eventually figure this out. Attributes are nodes. *beats self on head with mallet*
|
DiffDog does an excellent job of visually showing the differences between two XML documents. The "Export Differences" option produces a useful report. However, we want a combination of both: the report would be even more useful if there were an option to create an XML diff document that includes the entire content of the base document, plus changes. As it works now, you just get the differences with some context.
Perhaps it would help if I explained what we really want to do: create an HTML document that shows what has changed (preferably with hyperlinked TOC that takes you to the changed text). If we had output like I described in the previous paragraph, that would be doable--use an XSLT to insert HTML spans with styles showing deletions in red strikethrough and additions in green, or whatever.
Is there a way to make DiffDog create such a full report? If not, perhaps you would accept this as a feature suggestion for the next release.
|
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.
|
|
