RE: merge mode for XML

[Paul Sander]

Once again, take a look at message ID# address@hidden
posted to this forum on September 16, 2001.  It illustrates one way (though
perhaps not the best way) to do just this.  It relies on a lookup table that
looks up a diff tool given a file's name.

A better implementation would be to code a symbolic name for the merge tool
in a newphrase in the admin section the RCS file, and look up that symbolic
name on the client to locate the proper tool.

>--- Forwarded mail from address@hidden

>> A better approach is to avoid XML entirely in the first place
>> -- it's a
>> really really horrid syntax with all kinds of goo that's usually way
>> over-kill for the application, being SGML based and all that....


>I agree that XML is overkill, but the truth is that it is here to stay.

>XML is fastly becoming excepted as the defacto standard for data exchange.
>Opto 22 makes machine control sensors / PLC that publishes data in XML.
>Semen's is doing similar things from what I understand.  Java uses XML for
>all of the enterprise application descriptors.  It seems that I can't
>interface to machines, or program without looking at XML.

>If CVS had away to use modular plug in "diff" and "merge" programs, we could
>setup a wrapper file that would automatically diff/merge the file
>differently based on the extension.  e.g.:

>*.xml          xml_dm
>*.html html_dm

>This way we could write our own diff programs without having to understand
>all the complexities of tying into CVS code seamlessly.  Interfacing is much
>easier.  We could even take the XML diff/merge programs that are already
>available and just write wrappers for them.  No point in reinventing the
>wheel here.

>--- End of forwarded message from address@hidden