[Top][All Lists]

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

RE: merge mode for XML

From: Paul Sander
Subject: RE: merge mode for XML
Date: Mon, 29 Apr 2002 10:43:10 -0700

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

reply via email to

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