[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: XML Overlays and Deltas: Existing methods? Ideas?
- From: "Bullard, Claude L (Len)" <firstname.lastname@example.org>
- To: Joel Bender <email@example.com>, firstname.lastname@example.org
- Date: Wed, 18 Apr 2001 15:41:50 -0500
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
From: Joel Bender [mailto:email@example.com]
>...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.