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

[Tom Lord]

    > From: address@hidden

    > On Mon, Dec 22, 2003 at 10:33:12AM -0800, Tom Lord wrote:

    >> Pick your favorite generic XML-diff/patch tool and tell me under what
    >> conditions it is 

    >> (a) guaranteed to produce an XML document valid under that DTD when
    >>     applying diffs between meta.xml versions A and B to a meta.xml
    >>     version C.

    >> (c) guaranteed to produce a meta.xml output which is not only valid 
    >>     but useful

    > Are you aware that the standard diff/patch tools don't have
    > these properties wrt e. g. C-sourcecode? They just happen to
    > work most of the time, which seems to be enough to make them
    > useful.

Yes and that gets to the very essense of why we have these additional
requirements for office documents:

Consider the problem of helping a user review the effects of a merge.
With a plain-text file containing source code, that's pretty easy:
`tla changes' prints plain-text diffs.  By hand or with simple emacs
tools, a user can browse those diffs, compare them with the actual
source files, and so on.  Besides that, with a program, the results of
the merge are going to seen by a compiler; are going to run through a
test suite; etc.  So with plain-text source files the imprecision of
merging -- the fact that it sometimes produces nonsense results -- is
not much of a problem.  We have quick and easy ways to see when that
happens so the costs of guarding against occaisionally bogus merging
are overcome by the general ease of usually correct merging.

Word processor documents, spreadsheets, and so forth don't have those
safe guards -- at least not nearly as much.  We don't have an easy way
to show the user diffs.  Users don't have an easy way to relate those
diffs to the current contents of the document.  A bogus merge that
happens to quietly reverse the meaning of critical paragraph buried
deep in a 30 page report can easily escape notice; a merge that causes
a spreadsheet to incorrectly calculate a profit projection could cause
real havoc.  More basically than that: if a merge produces a file that
the document editor can't handle -- the user is up the creek without a
paddle unless he happens to be an XML-pro.

That's why I've been suggesting that beyond just simple validity
(merges always generating files the editor can actually load) we
almost certainly want merging to introduce _new_ markup, indicating
what the merge did, and helping the user to review the effects of the
merge.

(If users of office programs were more accustomed to working with 
plain-text source formats, then there would be less of a problem.
They could deal with merging just like programmers do.)



    > The special case of XML-diff/patch could be solved e. g. with an
    > XSLT-based mechanism for useful merges...


Very funny.

-t