[Standards] shared editing requirements

Peter Saint-Andre stpeter at jabber.org
Thu Aug 16 23:02:48 UTC 2007


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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070816/986c9efe/attachment.bin>


More information about the Standards mailing list