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

[Danny Ayers <danny@panlanka.net>]

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.

---
Danny Ayers
http://www.isacat.net

<- -----Original Message-----
<- From: Joel Bender [mailto:jjb5@cornell.edu]
<- Sent: 19 April 2001 02:21
<- To: Bullard, Claude L (Len); xml-dev@lists.xml.org
<- Subject: RE: XML Overlays and Deltas: Existing methods? Ideas?
<-
<-
<- Len wrote:
<-
<- >My question would be if the definitions are too heavy for the
<- >application of deltas.
<-
<- Too heavy for my head, at least!
<-
<- >Groves are too heavy for that.  XSLT might be a way to do it.
<-
<- ::sighs relief :-)
<-
<- >...if I wanted to apply it without a special engine, isn't this just
<- >a shorthand for an XSLT template?
<-
<- Perhaps it is.  My mental picture of an XSLT engine is one that
<- produces a new document given an old document and a template to
<- apply.  In my world, 99.99% of the document remains the same.
<-
<- Here is another view:  assume that two applications share a common
<- XML file that has been parsed and is loaded into an in-memory DOM.
<- The DOM has an interface facade that intercepts calls to
<- removeChild(), bundles that message into a small XML document,
<- broadcasts the document to everyone in the group, then continues the
<- call as usual.  I'm looking for the contents of the document.  If
<- there was an XML-RPC definition for the DOM functions, that might be
<- something to consider.
<-
<- I'm not against sending around little XSLT 'programs', as long as the
<- processing model can be "in memory replacement", which might not be
<- available in XSLT engines to date.
<-
<-
<- Joel
<-
<- ------------------------------------------------------------------
<- The xml-dev list is sponsored by XML.org, an initiative of OASIS
<- <http://www.oasis-open.org>
<-
<- The list archives are at http://lists.xml.org/archives/xml-dev/
<-
<- To unsubscribe from this elist send a message with the single word
<- "unsubscribe" in the body to: xml-dev-request@lists.xml.org
<-