[Standards] shared editing requirements - moderation? (games?)

Adam Nemeth aadaam at gmail.com
Thu Aug 23 20:11:09 UTC 2007


Hi,

I'm just thinking about rules of a collaborative session. In fact, a
strategy game, like chess is a collaborative session on a certain
model, (positions of white and black figures), which are edited
turn-based, but you can't cheat: I mean, you can't step with a horse
in diagonal, nor you can pass in a chess-state situation. Therefore a
game master is added for such situations (same applies for basicly all
games, even videogames).

But gaming and "shared editing" are only two edge cases of a
collaborative session. As a researcher I've seen many collaborative
things - like on a large multitouch-screen - and a moderator is
usually required to ensure certain 'model world' conditions are met.

Examples could be gravitation in some 3d environment, which aren't for
everybody.

So, could this be generalized a bit?

What do you think?

(I'd really appreciate comments from onlinegaming (chesspark) folks too)

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
>
>
>


-- 
Aadaam <aadaam at gmail.com>



More information about the Standards mailing list