[Top][All Lists]

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

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

From: michael josenhans
Subject: [Gnu-arch-users] Re: File-tpye plug-in architecture for Arch?
Date: Mon, 22 Dec 2003 19:54:01 +0100
User-agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5) Gecko/20031016

Andrew Suffield wrote:
> On Mon, Dec 22, 2003 at 03:33:21PM +0100, Thomas Zander wrote:
>>On Monday 22 December 2003 15:12, Andrew Suffield wrote:
>>>>If you say that then I must conclude you fail to appreciate what XML was >>>>created for. The whole point of XML based files is to abstract this kind
>>>>of functionality from lots of different domains into a generic one.
>>>No, that's the one thing that XML explicitly does not do. The whole
>>>point of XML is that it doesn't do *anything* with "functionality"
>>>(semantics): it is pure syntax.
>>Why is it so hard to understand that XML has achieved more then just being a
> Because it hasn't. Why is it so hard to understand the difference
> between syntax and semantics?

I consider the main difference between XML based documents and text based documents is that xml based documents are trees, while text based documents are flat.

The trees are written in recursive manner. This makes editing xml documents by hand a pain and validation of xml documents for being well formed (being according to XML standard) and valid (the tree node structure being accoring the grammar defined in the document type definition.) a must.

The difference above resuts in different change behaviour:
* Text documents: Are often modified, however the boundaries around the change stay intact. Thus the boundaries can be used as reference to merging. * In XML documents: The same tags are occuring in many places and nodes are often moved, deleted, split or merged. This makes XML-diff difficult. -However XML has other benefits, where can be taken advantage of, when files are merged: + The XML files must be well formed (e.g. all XML nodes opened, must be closed etc.) + The XML files can be validated according to the Document type Definition grammar. This grammar will restict a majot part of stupid node nesting an automated XML patch tools would do without. If this will not help enough to get XML diff working, we can use one of the following:
+ We could supply to the diff tool more info on how to resovle conflicts
+ If the XML tool knows the tree structure, a dedicated tool might be able to do smarter merge decisons. + If we have the XML data structure under control, we could build is some info we need for merging (amd especially branching). This will it make easier for the diff-tool to determine, what had changed. Examples would be tags with random number. These could be attached to some or all XML-nodes. (See arch discussion on implicit vs. explicit tagging.) + We could ask the tool we use to modify the XML tree to generate the patch information. + We could ask the tool we use to modify the XML tree to generate the tags information. + Track node changed over patches. E.g. patch branch_1_patch7 has moved or split a node, while patch branch_2_patch1 still relies that the node in in the previous position. (I have not seen that any currently available tool has managed to solve this trouble)


There is a commercial tool claiming to be able to handle diff3:

This company had created a very nice XML-demo for Scaled Vector Graphics (SVG).

Note: Press next on the end of the page.

They have also a nice web based diff, which I used to create the attached diffs.


Description: Zip archive

reply via email to

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