gnu-arch-users
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Tom Lord
Subject: Re: [Gnu-arch-users] Re: File-tpye plug-in architecture for Arch?
Date: Mon, 22 Dec 2003 07:51:12 -0800 (PST)

    >>= Tom Lord

    >> On the one hand, sure, you could abstract the `cmp' and
    >> conceptually the world doesn't fall apart.

    >> But on the other hand, that would mean (for example) that `get'
    >> would sometimes return a tree whose source files are not
    >> byte-wise equivalent to those that were passed to `commit'.
    >> It's a pretty big leap of faith to think that that's desirable.

    >= Thomas Zander

    > If a file is an honest XML file I fail to see why this would be a problem;

Because it also an honest regular byte-stream file.   For example,
a typical md5-sum program will see it as such.


    >> I'm not at all convinced that generic XML-diff/patch tools are what
    >> you ought to be looking at.   They only make sense if, either
    >> deliberately or by accident, the document formats are robust and
    >> meaningful under the transformations of a generic XML-diff/patch.

    > That is the whole point of such diffing tools and XML in
    > general. So you can assume they are [robust].

So you are saying that open office can open an arbitrary file produced
by this XML-diff/patch process from files earlier written by open
office and will always display the contents correctly and reasonably?  
That seems implausible if XML-diff/patch is operating, essentially
blindly, just on the tree-structure of the XML.


    >> I think it unlikely that the document formats were designed with any
    >> XML-diff/patch algorithm in mind.   I think it implausible that they
    >> will be robust under those transforms "by accident".

    > Then you have not read the XML specs which says otherwise.  In
    > short an XML will be plainly rejected (and not parsed at all) if
    > the formatting is incorrect.  This is a good thing.  As someone
    > who wrote the file format for KOffice, please take my word for
    > it that this is no problem if you are talking about real XML
    > files.

I've no doubt that a proper XML-diff/patch will produce a
syntactically valid XML file given syntactically valid XML inputs  --
that is not the issue.

The question is whether they will produce (a) valid and then (b) sane
OO documents given valid and sane OO document inputs.

-t





reply via email to

[Prev in Thread] Current Thread [Next in Thread]