[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

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

  • From: Danny Ayers <danny@p...>
  • To: Joel Bender <jjb5@c...>,"Bullard, Claude L (Len)" <clbullar@i...>, xml-dev@l...
  • Date: Thu, 19 Apr 2001 18:51:51 +0600

xml overlays
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!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.