[Standards] shared editing requirements

Joonas Govenius joonas.govenius at gmail.com
Fri Aug 17 06:10:48 UTC 2007


On 8/17/07, Peter Saint-Andre <stpeter at jabber.org> wrote:
> Here is my first attempt at summarizing the requirements for shared XML
> editing applications such as whiteboarding. The use of must and should
> is approximate. Not all of these requirements need to be addressed by a
> single specification. The requirements are not necessarily grouped by
> category. Further refinement will be necessary. This is a first pass.
>
> OK, here goes...
>
> 1. The underlying protocol is designed for synchronization of XML
> instances between entities that communicate via XMPP.
>
> 2. By "synchronization" is mean that all parties to a shared XML editing
> session must have the same representation of the XML object after all
> synchronization messages have been processed.
>
> 3. Ideally, it should be possible to use the protocol for multiple
> application types, e.g. SVG whiteboarding, XHTML document editing,
> collaborative data objects (XEP-0204).
>
> 4. There is no requirement to synchronize non-XML data.
>
> 5. It must be possible to synchronize XML object instances either
> between two entities or among more than two entities.
>
> 6. The protocol should not (unduly) limit the number of parties to a
> shared XML editing session.
>
> 7. It must be possible to use the protocol "directly" between two
> entities without assistance from intermediaries, either via an XMPP
> server (RFC 3920) or in serverless mode (XEP-0174).
>
> 8. It must be possible to use the protocol through a multi-user chat
> (XEP-0045) room.
>
> 9. It should be possible to use the protocol with a specialized
> synchronization component attached to an XMPP server.
>
> 10. Where possible, all edits should be commutative in order to minimize
> the need for locking of the XML object.
>
> 11. The protocol should be as lightweight as possible in order to
> minimize bandwidth consumption.
>
> 12. It must be possible to add new "nodes" (elements and attributes) to
> the XML object.
>
> 13. It must be possible to edit existing nodes.
>
> 14. It must be possible to remove existing nodes.
>
> 15. It should be possible to move a node from one location to another
> within the XML object.
>
> 16. It should be possible to re-use the XML object outside of a shared
> editing session (e.g., for offline editing in a different application,
> or for archiving).
>
> 17. It should be possible to specify the version of the protocol.
>
> 18. It should be possible to refer to outside resources (e.g., images
> hosted at websites) from within the protocol.
>
> 19. It should be possible to retrieve the current state of the XML
> object from a party to the shared editing session.
>
> 20. It should be possible to retrieve the history of edits to the XML
> object from a party to the shared editing session.
>
> 21. It must be possible to discover whether another entity can engage in
> a shared XML editing session.
>
> 22. It must be possible to discover which application types another
> entity can handle.
>
> 23. It must be possible to initiate, update, join, and terminate a
> shared XML editing session.
>
> 24. It must be possible to specify the roles of parties to a shared XML
> editing session.
>
> 25. It must be possible to uniquely identify each node in an XML object,
> both within the scope of a standalone shared XML editing session and if
> the edited object is shared with other appliclations or embedded in
> other objects.
>
> 26. It should be possible to validate synchronization messages against a
> defined schema for the application type in real time.
>
> 27. It must be possible to reject out-of-order synchronization messages.
>
> 28. It must be possible to specify the parent of any given node.
>
> 29. It should be possible to query an entity for the shared XML editing
> sessions to which it is a party.
>
> 30. It should be possible to query an entity for the XML objects it owns
> or knows about (which may be the result of a past editing session).
>
> 31. It should be possible to send the complete content of a node or only
> the difference between the last version of the node and the current version.
>
> 32. It should be possible to declare shared editing of the XML object to
> be complete (e.g., in preparation for archiving of the XML object or
> editing by another application).
>
> 33. It should be possible to declare shared editing of part of the XML
> object to be complete.
>
> 34. It should be possible to associate an XML object with other XML objects.
>
> 35. It should be possible to specify that all parties shall move their
> viewing context to a particular location in the XML data object.
>
> 36. It must be possible to represent human-readable text in a language
> and character set appropriate for a human user.
>
> 37. Certain applications may need to handle particular features of the
> XML syntax for that application type (e.g., layers in SVG or pages in
> XHTML); the protocol must not forbid such specialized semantics.
>
> 38. It should be possible to associate relevant metadata with each node
> in the XML object, which might include time of creation, identity of the
> creator, time of last modification, and identity of last modifier.
>
> 39. It should be possible to log all synchronization messages and
> associated metadata for archiving and logging purposes.
>
> END
>

Peter, this is great!

I have one more requirement that sxde currently struggles with.

40. It should be possible to mix text nodes with other child nodes
(namely elements).

E.g. <parent>some <element/> text</parent>.

This is a big pain as you can't serialize the necessary metadata (like
a unique id) of a text node into an XML attribute of the node. You
also can't serialize two consecutive text nodes to distinct XML nodes
(e.g. "so" and "me ").

Hence sxde currently violates requirement 25 by requiring that if any
of the ancestors of a a node have mixed content like this, the node
must not have an id. Consequently, you can't modify <element/>
separately from "some " and " text" (and hence requirement 10 is also
violated).

Alternatives I could think of would be to somehow store information
about each node outside the document or to disallow mixed content
altogether and require something like
<parent><span>some </span><element/><span> text</span></parent>
but both seem less than ideal.

This requirement isn't really necessary for SVG but would certainly
seem useful for XHTML for example.


Joonas



More information about the Standards mailing list