Re: [Gnu-arch-users] Re: File-tpye plug-in architecture for Arch?

[Tom Lord]

    > From: michael josenhans <address@hidden>

    > Andrew Suffield wrote:

    >> A generic XML diff tool will probably not perform sufficiently better
    >> than diff(1) to be worthwhile. A good domain-specific diff actually
    >> understands the file it's operating on.

    > I think this applies to manually changed files. However not to files red 
    > completely by e.g. an XML DOM parser, modifed sub in some areas and 
    > saved again. The file content may stay indentially in most areas, while 
    > the layout might have been changed everywhere as there are many placed 
    > in XML, where space and carriage retrun have no relevance.

    > The XML file I took out off OO, did not contain any single carriage 
    > retrun. Such a file will not work with any traditional line based diff 
    > tool.

    > The XML diff-tool was indeed be able to create useful patches.

I think you missed Andrew's point.

You need a tool for diffing and patching (or diff3-style merging)
among _any_ three valid documents with the strong guarantee that the
output is a valid document and at least a strong hope that the output 
is a sane merge from the user's perspective.

That you can XML-diff/patch a few sample OO files doesn't give you
that strong guarantee of always producing valid output -- you need to
actually study both the diff/patch algorithm and the OO format and
then prove it works.  (And then you need to hope that future revisions
to the format don't break that).

As for what would make a "sane merge" -- programs come with ways to
test them afterwords and with ways to look at "what-changed" (tla
changes) before committing.   So we tolerate some edge cases in which
a merge makes a bogus change because it is easy to catch that before 
it gets very far.

Documents don't have the same kind of tests.   A bogus merge might
completely change the meaning of some paragraph and the only way to
catch that is with careful and comparative proofreading.   If that
proofreading is hard to do, then the cost of using a merge tool
probably outweighs the benefits.

So, for example, I would expect a tool that merges two branches of a
document to introduce something like "changebar markers" -- to not
silently incorporate the changes into the merged-into document, but to
make those changes while adding brand new mark-up that calls the
attention of proofreaders to the changes, showing them both the before
and after text.

If the proofreading task can be made very efficient and easy, _then_ a
merge tool could be very helpful.   But to make a mergetool that helps
proofreaders suggests that, indeed, generic XML-diff/patch tools won't
cut the mustard.

-t