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

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

Interesting.  Basically a dispatch system similar 
to how mobile units are handled by 
Computer-aided Dispatch Systems that have to 
update location and event displays.

Keep us informed.   

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

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


-----Original Message-----
From: Joel Bender [mailto:jjb5@cornell.edu]
Sent: Thursday, April 19, 2001 3:00 PM
To: Bullard, Claude L (Len); Danny Ayers; xml-dev@lists.xml.org
Subject: RE: XML Overlays and Deltas: Existing methods? Ideas?


Len Bullard wrote:

>Yes, I thought about the SAX approach too.  When in doubt,
>write your own handler and trap the XML types.

Yesterday I just "discovered" the MutationEvent object in DOM Level 
2, so I'm considering serializing the event for archive and 
redistribution.

Danny Ayers wrote:

>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.

It needs to be serialized because it is going to be broadcast to 
other applications on different platforms.  A user interactive view 
of the document will be on a Macintosh, routers required to interpret 
the contents as a network topology will be running a C++ application 
on Linux, and supervisory applications that monitor the changes and 
provide a web view will be something else.

I will also be changing more than just leaves (text nodes and 
attribute values), elements and lists of elements may need to be 
added/deleted/etc.

>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.

Lucky for me I can avoid the issue because my documents are slightly 
simpler than CommonXML [1] without Clause 3, where there are no 
entities to expand (apart from the built-in ones).  I will have 
namespaces to contend with, but I'm attempting to postpone that a 
little.

>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).

Here is a picture forming in my head: each DOM in each application 
has an engine (mutation event listener) associated with it.  All of 
the engines associated with a document are members of the same 
multicast group (perhaps the group name is based on the document URL) 
and can reliably send/receive a message to/from the group.

The engine (a) listens for mutation events, serializes them, and 
sends the resulting message to the group.  It also (b) listens for 
messages from peers, decodes the message into a mutation event object 
and applies that to its DOM.  That should keep the DOMs in virtual 
synchrony [2].

Each application will have an additional mutation event listener that 
"hears" changes made from the engine (and probably its own changes as 
well).  It's up to the application to recognize if the change is 
meaningful to its own operation.

>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.

I think I will, and that's not such a huge beast.

>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.

I agree, and while I don't expect it to happen very often, I still 
need to plan for it.  I have other synchronization problems to 
consider as well.


Joel

[1] http://www.simonstl.com/articles/cxmlspec.txt
[2] http://www.cs.cornell.edu/Info/Projects/HORUS/