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" <[EMAIL PROTECTED]> 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 >
