OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

I think I understand, but let me noodle a bit.

Given two documents, they are similar or equivalent 
if they are transformable into each other.

To use a transform-based operation against a document 
set, the documents must be closed, that is, a transform 
must exist which will update/insert/append the information 
and not violate similarity if the SAME operation is 
applied to all.

The worst case pathology requires a complete replacement 
of the document itself.

So the delta update could be a transform based message 
type given that such a transform exists for the class 
(in fact, the existence of the transform proves the 
existence of the class in that sense).

It seems to me in the theoretical that the XSLT 
transform can represent the delta.  If I have a 
document loaded into the DOM, can't I listen 
for transforms by type (ie., I have to identify 
which of the transform messages are mine)?


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

-----Original Message-----
From: Joel Bender [mailto:jjb5@cornell.edu]

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