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

[michael josenhans]

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
>>syntax.
>
>
> 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)

deltaXML
--------

There is a commercial tool claiming to be able to handle diff3:
http://lists.xml.org/archives/xml-dev/200207/msg00517.html
http://lists.xml.org/archives/xml-dev/200312/msg00160.html


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

http://www.deltaxml.com/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.

Michael

delta-results.zip
Description: Zip archive