[Standards] Best approach for Shared XML editing

Dave Cridland dave at cridland.net
Thu Sep 11 23:18:48 UTC 2008


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:dave at cridland.net - xmpp:dwd at dave.cridland.net
  - acap://acap.dave.cridland.net/byowner/user/dwd/bookmarks/
  - http://dave.cridland.net/
Infotrope Polymer - ACAP, IMAP, ESMTP, and Lemonade



More information about the Standards mailing list