RE: XML Overlays and Deltas: Existing methods? Ideas?

["Bullard, Claude L (Len)" <clbullar@ingr.com>]

Yes, I thought about the SAX approach too.  When in doubt, 
write your own handler and trap the XML types.  As James 
pointed out though, there is still the issue of entity 
expansion but I would think one would plan for the 
identity issues in the updates.  I haven't thought 
the whole operation model through.  SAX would appear 
to be faster but I am wary of untested assumptions 
like that (see the binary discussions).

What I was considering in his problem was if a new 
XML language for the updates is necessary or whether 
he could adapt XSLT for that.  I should think he would 
have to cobble together an engine anyway.   We've talked 
about this stuff before locally and the problems of 
ensuring a transform exists for all documents (eg, 
don't break because of structural differences) were a 
limit.  That is why the degenerate case of replacing 
the whole document had to be considered.

Len 
http://www.mp3.com/LenBullard

Ekam sat.h, Vipraah bahudhaa vadanti.
Daamyata. Datta. Dayadhvam.h


-----Original Message-----
From: Danny Ayers [mailto:danny@panlanka.net]
Sent: Thursday, April 19, 2001 7:52 AM
To: Joel Bender; Bullard, Claude L (Len); xml-dev@lists.xml.org
Subject: RE: XML Overlays and Deltas: Existing methods? Ideas?


I would have thought the big issue was whether or not the (whole) data needs
to be in serial form at all - if not then all you need to communicate is the
particular leaf and its new value, which should map easily enough from one
DOM tree to another. If the data does need to be serialized, it's a
different ballgame - XSLT would sound the best solution, though it might be
worth considering using SAX (+ handler) to echo the XML through but trap any
elements of a particular form/value  (like a crude kind of XSLT). I'm
thinking this approach could mean the system wouldn't be as smart as XSLT,
so could perhaps be faster. Just a thought.