[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: XML Overlays and Deltas: Existing methods? Ideas?
- From: Joel Bender <firstname.lastname@example.org>
- To: "Bullard, Claude L (Len)" <email@example.com>,Danny Ayers <firstname.lastname@example.org>, email@example.com
- Date: Thu, 19 Apr 2001 16:00:22 -0400
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
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
>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  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
>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
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.