[Standards] shared editing requirements

Boyd Fletcher boyd.fletcher at je.jfcom.mil
Fri Aug 17 13:41:44 UTC 2007


good summary.

WRT: 19 and 20, by XML object are you referring to the entire document or a
specific element? if the later, then the entire document is also required.
For sending of the current state there must be a way to get the current
state without sending all the changes made to get to the point.


also need:

- ability to maintain ordering of XML elementd in the document
- ability to leverage the permissions from MUC not just run inside muc.
- ability to get all the changes to the XML document since a specific
sequence number


On 8/16/07 7:02 PM, "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
> 



More information about the Standards mailing list