Several users have reported problems of data loss when passing files between programs. With XML and the Document Object Model, this will never happen, because it's easy for a programmer to work on the document tree, just adding nodes where additions have been made by user, and leaving the other parts unchanged. So a round-trip beetwen programs will be feasible, leading to a composite document having a common core of elements understood by both programs, some elements understood by program A only, and some by program B only.

Indeed, so long as the subset of elements shared by the two applications are handled correctly in both cases. Application A may decide to encode a date as simply year-month-day. Application B may decide to encode it as year-month-day-time. Load file from Application B into Application A and unless you're careful you may lose precision.

Also consider the following:

<character number="8"> <description>outer edge of front wing</description> <comment>shape</comment> <multi type="unordered"> <state number="1">convex</state> <state number="2">straight</state> <state number="3">concave</state> <state number="4">irregular</state> </multi> </character>

<application-B-tag references="8"> I referred to standard chart X to finally decide on shapes. </application-B-tag>

Application A, ignoring the application B specific tag, on request of the user deletes character 8. Now load the file up into application B and you've got a problem - you've lost the character being referenced.

XML does not solve these problems. Although it brings us closer to a toolkit that does. Data modelling and agreeing on standard (extension formats) will help to solve these problems.

See http://www.bath.ac.uk/~ccslrd/delta/#adv, particularly "xml is not a magic bullet" and the references to postings on the XML-DEV mailing list.

Sorry to pick holes, but I'd hate for XML to be oversold to the participants on this list. Its important to see beyond the hype.

Cheers,

L.