On Thu Sep 11 22:01:35 2008, Joonas Govenius wrote:
RFC 5261 looks like a handy diff format but it doesn't solve the
core
problem of dealing with simultaneous modifications. The problem with
XPath based approaches in general is that the node the XPath
selector
referred to in the sender's copy might not be the same node that it
refers to in the receiver's copy if other modifications have taken
place in the mean while. There are basically three ways to resolve
this issue:
Worth noting it's not intended to solve the problem of simultaneous
modifications, it's designed to express the modifications. Processing
rules to handle them are a different thing.
3) You can give each node a unique id that can be used to address it
instead of the XPath selector. This is the approach that sxe uses
because it is very simple and flexible. The client simply needs to
maintain an _unordered_ set of records (each describing an XML node)
that can be mapped to a unique XML document based on the contents,
not
the order, of those records.
Of course, you can explicitly give things in an XML document xml:id
attributes. You can even do it on the fly with RFC 5261 - add a
stable identifer with XPath (unstable refs), then do lots of work
with the element.
Furthermore, the namespace issues described in RFC 5261 are avoided
by
letting the protocol send "records" rather than inline XML.
Sure, but then again, look at example 13 of SXE.
Here you have record GUID1 - so far, so good. It's
<{http://www.w3.org/1999/xhtml}html/>, and that's a known, qualified
element.
Next, an attribute {xml}:lang is added with a value of 'fi', and then
the value is subsequently changed to 'en'. Great compact
representation. Only the namespace is incorrect, of course, it should
be the one specified in XML-NAMES, since you need the namespace
itself there, not the prefix.
But then it goes really wrong. A local element, <head/> is added
below the qualified <html/> element. In XML, at this point, we have:
<ns0:html xmlns:ns0='http://www.w3/org/1999/xhtml' ns1:lang='en'
xmlns:ns1='xml'>
<head/>
</ns0:html>
Which is not what you wanted at all. To have the <head/> element
qualified, this needs spelling out in SXE, which really isn't very
efficient. Or else the ns defaults to the parent - but that can't be,
because there'd be no way of specifying a default element, then.
In other words, Example 13 is significantly smaller than it really
has to be according to the specification, and that's really not good
given how huge it is to begin with. And remember, this is to
ultimately generate:
<html xmlns='http://www.w3.org/1999/xhtml' xml:lang='en'>
<head>
<title><!--The title of the document goes here.-->Royal
Musings</title>
<body/>
</html>
(You'll note that I've corrected the actual output given later in
Example 16, since that's wrong even discounting the namespace issue).
So I'll grant you that by forcing the actors to exchange vast swathes
of XML-encapsulated XML, with no possibility for reducing redundancy,
you're removing the need to deal with the complexities of namespace
issues.
But I'm also intrigued - I wonder how big a document one must be
working on, and for how long, before it becomes cheaper to use SXE
over simply retransmitting the entire document each time it's changed?
Dave.
--
Dave Cridland - mailto:[EMAIL PROTECTED] - xmpp:[EMAIL PROTECTED]
- acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
- http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade
