[Standards] Best approach for Shared XML editing

Joonas Govenius joonas.govenius at gmail.com
Thu Sep 11 13:29:29 CDT 2008


Hi Yann,

On Thu, Sep 11, 2008 at 11:43 AM, Yann Biancheri <ybiancheri at wimba.com> wrote:
> Hi everybody,
>
> We are looking at ways to implement whiteboarding over XMPP and we've found
> lots of interesting proposals in the community already. We are particularly
> interested in the sxe [1] and sxde [2] ones. It seems that sxde has been
> written first and has leads to sxe. What we like with sxde is that it is
> less verbose than sxe since you can directly add an xml element qualified
> with it's namespaces, attributes, contents whereas in sxe you would have to
> issue one command to create the element, and one for each of the attributes
> which in the end result in a lot of xml to send in the XMPP band. On the
> other hand, sxe is more recent, seems cleaner and more generic.
> We were wondering if there were any other reasons such as protocol flaws
> behind the move from sxde to sxe?  Or if we could use one or the other
> eitherway?

Your observations are correct. "SXDE" was one of the first versions of
the protocol and was later renamed "SXE". Lots of other renaming and
minor shuffling has also been done (e.g. 'configure' -> 'set') between
the versions, but the most significant change is the change from an
element-based approach to a node-based approach.

There were a few reasons why I decided to shift from an element-based
approach (sxde) to a node-based approach (sxe):

1. A practical limitation of the method described in the older version
(sxde) is that it is impossible to make mixed content mutable (e.g.
'<div>A <strong>bold</strong/ word</div>') because the text nodes are
not addressable as they don't have an id. For SVG whiteboarding this
might not be a huge issue but it's a pretty big limitation in general.

2. In some applications (like Inkscape) that are just a part of a tool
chain and you actually need to post-process the produced XML in other
tools, it's inconvenient to have extra fluff added to the elements
(e.g. the 'sxde:id' attributes).

3. It seemed cleaner and more elegant to simply treat any XML node
identically (instead of making a distinction between text nodes,
element nodes, attribute nodes, etc.), and that did cause a
significant increase in the bandwidth requirements. It would be
possible to revert to some kind of hybrid between the old and the new
versions where attributes for example would be addressable only
indirectly through the element. However, rather than that, I thought
it would be cleaner to first perfect the completely node based
approach, and later add 'shortcuts' (that would map 1-to-1 to regular
<new/> elements) for common operations, like adding an element node
with attributes.

4. The sxe protocol could easily be mapped to a binary protocol for
use over Jingle data channels for example, while doing this with sxde
is much more difficult because the content is "inlined" as actual xml.
This wasn't really a consideration at the time but has later occurred
to me.


There is also a further improvement to sxe that's not really
documented anywhere yet that would make it insensitive to delivery
order of messages, which would be nice particularly for Jingle based
connections. I've outlined it here:
http://mail.jabber.org/pipermail/sharedediting/2008-May/000005.html.

Finally, I think it would be a good idea to make the protocol
insensitive to receiving the same <sxe/> twice by storing some
identifying information about each received <sxe/> element. If this
information was also sent to new clients that join, they could easily
filter out the <sxe/> elements that have already been incorporated to
the document they received. This would remove practically all
remaining restrictions on the underlying transport method used to
deliver the <sxe/> elements.

However, I admit that I haven't followed through with these updates
because I decided to give all this sxe/whiteboarding stuff a break for
a while. However, just last week I actually started tweaking the Psi
implementation again so hopefully something useful will come out of
that soon.


Joonas


More information about the Standards mailing list