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

[michael josenhans]

Tom Lord wrote:
>     > From: Thomas Zander <address@hidden>
>
>     > On Monday 22 December 2003 16:23, Andrew Suffield wrote:
>     > > > Could you point out what the expected result would be since I see no
>     > > > difference between this and the plain-text approach of merging.
>
>     > > Well, duh. That's because diff(1) doesn't understand it either. By
>     > > pure heuristics it happens to do the right thing more often than not
>     > > for source code and english text. It's wrong for almost everything
>     > > else.
>
>     > XML is very very different from binairy text; as applications will ignore 
>     > ordering of Elements when ordering is not needed so you are allowed to switch 
>     > ordering without anything breaking (for example)
>
> Asuffield delights in being terse yet correct.  He is talking over
> your head.

Not sure.

>     > I find it quite annoying that you (plural) simply tell others they are wrong 
>     > since you can't see how the solution could work.
>
> You're making fundamental, non-obscure, mathematically certain errors
> in your proposed solutions.  "We" find it annoying to have to point
> this out again and again.
>
> But let me try again anyway.
>
> OO document bundles can contain a "meta.xml" file.   The contents of
> that file are constrained to an XML subset defined by a DTD.
>
> 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.

That is what I would expect from such tools. I think some tools I have 
seen do this already.

An application must be able to cope with any valid meta.xml file.

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

Defintely not.

> (d) guaranteed to produce byte-wise identical-to-B output when
>     applying the diff between versions A and B to A.

It will generate an XML equivalent XML file.

xml-diff(patch( A, xml-diff(A,B)), B) = empty.

> Repeat that for each of the other XML-subset types used in OO format.

The statements above will apply to all diff files.

> At _best_ (from your perspective): you have expressed a _hope_ that
> these questions have good answers; asuffield (and others) have given
> plausible arguments (very nearly proofs) that those questions _don't_
> have good answers.
>
> And at _second_best_ you are backtracking to say "well, we won't use
> the XML-diff/patch tools for _that_" but then why would we bother with
> them at all when ordinary diff or xdelta would do just as well for the
> more restricted purposes?

I do not see how tranditional patch tools help with XML-files, 
especially thosed edited with various dedicated XML or other dedicated 
editors.

Likely every SVG editor will save an SVG file with a different layout 
and represenation.

Michael