From: Paul Sander [mailto:address@hidden
Sent: Monday, April 29, 2002 12:43 PM
To: address@hidden; address@hidden
Subject: RE: merge mode for XML
Once again, take a look at message ID#
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
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
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
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.:
This way we could write our own diff programs without having
all the complexities of tying into CVS code seamlessly.
Interfacing is much
easier. We could even take the XML diff/merge programs that
available and just write wrappers for them. No point in
--- End of forwarded message from address@hidden