-----Original Message-----
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#
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