[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] 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. --- Danny Ayers http://www.isacat.net <- -----Original Message----- <- From: Joel Bender [mailto:jjb5@c...] <- Sent: 19 April 2001 02:21 <- To: Bullard, Claude L (Len); xml-dev@l... <- 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@l... <-
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|