XEP-xxxx: Shared XML Document Editing

This XEP defines a protocol that allows clients to share and collaboratively edit an XML document.


WARNING: This document has not yet been accepted for consideration or approved in any official manner by the Jabber Software Foundation, and this document must not be referred to as an XMPP Extension Protocol (XEP). If this document is accepted as a XEP by the XMPP Council, it will be published at <http://www.xmpp.org/extensions/> and announced on the <standards-jig@jabber.org> mailing list.


Document Information

Status: ProtoXEP
Type: Standards Track
Number: xxxx
Version: 0.0.3
Last Updated: 2006-01-09
Publishing Organization: Jabber Software Foundation
Approving Body: XMPP Council
Dependencies: XMPP Core, XMPP IM
Supersedes: XEP-0113
Superseded By: None
Short Name: Not yet assigned

Author Information

Joonas Govenius

Email: joonas@uwc.net
JID: joonas@jabber.org

Legal Notice

This Jabber Enhancement Proposal is copyright 1999 - 2006 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy (http://jabber.org/jsf/ipr-policy.php). This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/).

Discussion Venue

The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The following keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".


Table of Contents

1. Introduction
2. Requirements
3. Glossary
4. Use Cases
4.1. Querying SXdE Abilities
4.2. The Main sxde Element
4.3. Initiating and Joining a Session
4.3.1. Invitation to a New Session
4.3.2. Aborting Negotiation
4.3.3. Connecting to a Session
4.3.4. Offering to Send the State
4.3.5. Accepting a State Offer
4.3.6. Sending the State of the Document.
4.4. XML Document Requirements
4.5. Element Edits and Commutative Edits
4.5.1. Requirements for the Server Component
4.6. Commutative Edits
4.6.1. Creating New Elements
4.6.2. Removing an Element
4.7. Element Edits
4.7.1. configure Element
4.7.1.1. attribute Element
4.7.1.2. remove-attribute Element
4.7.1.3. content Element
4.7.1.4. parent Element
4.7.2. Processing a Configure Element
4.7.3. Changing the Order of Elements
5. Implementation Notes
6. Security Considerations
7. IANA Considerations
8. Jabber Registrar Considerations
8.1. Protocol Namespaces
8.2. Service Discovery Identities
9. XML Schema
10. Acknowledgements
Notes
Revision History


1. Introduction

The need for this protocol initially arouse from an attempt to develop a protocol for collaboratively editing an SVG document for the purpose of whiteboarding. However, it was soon realised that the developed method was more general and can be applied to collaboratively edit any given XML document with one major limitation; mixed content can only be modified in so called leaf nodes.

A special feature of this protocol compared to most other collaborative editing tools is that no master or server entity is required. A specialized MUC component can, and should, however be used for sessions that are large, need to be persistent or require access control over who can modify the document. However, whether such specialized MUC component is used or not and whether the session is one-to-one makes a minimal difference to the client implementation.

2. Requirements

  1. The protocol must allow for a common XML document to be shared and edited by any number of clients.
  2. Each client must have identical copies of the common XML document once all the sent messages have been delivered.
  3. The protocol must allow three modes of operation: one-to-one, multiuser with regular MUC component as the transport and multiuser with a specialized MUC as the transport. Yet, all of these modes should be as close to identical as possible from the client's perspective.
  4. The protocol should minimize the amount of "locking" on the document. I.e. edits should be commutative where possible.
  5. The protocol SHOULD be light-weight where that doesn't unproportionetely complicate the implementation.

3. Glossary

id of an element: refers to the the 'id' attribute of the SXdE namespace; not the xml:id attribute. This attribute MUST NOT be changed after the creation of the element.

Z value of an element: Primarily, the z value of an element is represented by the 'z' attribute of the SXdE namespace. The value of this primary part of the z value MAY be changed like any other attribute. Secondarily, if the values of the 'z' attributes of two elements are equal, the first differing characters in the corresponding 'id' attributes are compared by their Unicode values. The higher the character the higher the z value of the element.

Leaf node: An element that has no chidren with id's.

History of the document: a complete record of all the edits (both commutative and element edits) sent to the session, excluding the <negotiation/> elements. Only the server component, if there is one, is REQUIRED to keep this record.

State of the document/the state: In the context of a new user joining, the state refers to a reduced (and modified) version of the history of the whiteboard that is necessary to reconstruct the current content of the document. All entities involved in the session are REQUIRED to keep this state.

4. Use Cases

4.1 Querying SXdE Abilities

Before attempting to establish a session, the user SHOULD use Service Discovery or Entity Capabilities to find out whether the intended peers support SXdE:

Example 1. Service discovery request

<iq from='kingclaudius@shakespeare.lit/castle' to='laertes@shakespeare.lit/castle' type='get' id='disco1'>
	<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

If a peer supports this protocol, it MUST return a feature of "http://jabber.org/protocol/sxde":

Example 2. Service discovery response

<iq from='laertes@shakespeare.lit/castle' to='kingclaudius@shakespeare.lit/castle' type='result' id='disco1'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='http://jabber.org/protocol/sxde'/>
    ...
  </query>
</iq>

4.2 The Main sxde Element

All SXdE elements MUST be contained in a <sxde/> element which MUST posess the following attributes:

Table 1: Attributes of <sxde/> element

Attribute Description
xmlns REQUIRED and MUST be "http://jabber.org/protocol/sxde"
xmlns:sxde REQUIRED and MUST be "http://jabber.org/protocol/sxde#metadata"
id REQUIRED and MUST be a sequence of characters that is unique within the set of <sxde/> elements sent by the user.

Example 3. Initiating a new session

<message 
	from='kingclaudius@shakespeare.lit/castle'
	to='laertes@shakespeare.lit/castle'
	type='chat'>
	<sxde xmlns='http://jabber.org/protocol/sxde'
	    xmlns:sxde='http://jabber.org/protocol/sxde#metadata'
	    session='851ba2'
	    id='a'>
		[sxde messages]
	</sxde>
</message>

4.3 Initiating and Joining a Session

The process for establishing a new session:

  1. The initiator sends an invitation to a user or the JID used for relaying the messages (the target JID).
  2. The receivers of the invitation reply by aborting the negotiation or by following the process for joining an existing session.

The process for joining a session:

  1. The joiner sends a connect request to a session.
  2. The joiner receives state offers from the participants of the session.
  3. The joiner accept the first offer it receives and aborts the negotiation with the rest.
  4. The participant whose offer was accepted sends the state of the document to the joiner.
  5. Session joined. The document is again ready to be modified by all users.

Any of the negotiating users may abort the negotiation at any point for their part.

All of the negotiation messages MUST be contained in a <negotiation/> element.

In case a specialized MUC component is used, it MUST accept the first invitation it receives and send this invitation to all clients that are currently connected or connect later. It MUST also intercept and reject all further invitations as there should only be one SXdE session per room. It MUST also intercept the connect requests from clients wishing to join and send the state to them.

In case a specialized MUC component is not used, clients already in an SXdE session in a room MUST respond to invitations to further sessions by aborting the negotiation with the appropriate message instructing them to join the existing session.

4.3.1 Invitation to a New Session

To establish a session the initiator needs to send a <invitation/> element to the target JID. The element MAY contain <feature/> elements if the XML document conforms to a specific standard and needs special treatment. For example, if the document represents a whiteboard in the format specified by http://jabber.org/protocol/whiteboard, it should include that feature so that clients supporting the whiteboarding know to display the document visually and clients not supporting the additional standard know to not join.

Example 4. Invitation to a new session to share an whiteboard session

<message 
	from='kingclaudius@shakespeare.lit/castle'
	to='laertes@shakespeare.lit/castle'>
	<sxde xmlns='http://jabber.org/protocol/sxde'
	    xmlns:sxde='http://jabber.org/protocol/sxde#metadata'
	    session='851ba2'
	    id='b'>
		<negotiation>
			<invitation>
				<feature var='http://jabber.org/protocol/whiteboard' />
			</invitation>
		</negotiation>
	</sxde>
</message>

4.3.2 Aborting Negotiation

If a user receives an <invitation/> element and doesn't wish to join the session, the user SHOULD reply with an <abort-negotiation/> element to acknowledge the invitation.

Any user may use this message at any point of the negotiation in order to back out from the negotiation.

The <abort-negotiation/> element MAY also contain a reason for the abortion:

Table 2: Abort Reasons

Element name Description
supported-features This element MAY be included if the reason for abortion was that the session uses features that are not supported by the user. The <supported-features/> MUST contain <feature/> elements which specify the features the client does support.
in-session This element MUST be included if the reason for abortion was that a session already exists between the two users in the room. The <in-session/> element MUST contain the session identifier of the existing session. Note that multiple sessions are allowed between two users but SHOULD NOT take place in a room.
no-session This element MUST be included if the abortion is a response to a connect request to a session that the entity is not part of.

Example 5. Backing out from a negotiation because of unsupported features

<message 
	from='laertes@shakespeare.lit/castle'
	to='kingclaudius@shakespeare.lit/castle'>
	<sxde xmlns='http://jabber.org/protocol/sxde'
	    xmlns:sxde='http://jabber.org/protocol/sxde#metadata'
	    session='851ba2'
	    id='c'>
		<negotiation>
			<abort-negotiation>
				<supported-features>
					<feature var='http://jabber.org/protocol/chess' />
					<feature var='http://jabber.org/protocol/gallery' />
				</supported-features>
			</abort-negotiation>
		</negotiation>
	</sxde>
</message>

Example 6. Backing out from a negotiation because a session exists

<message 
	from='laertes@shakespeare.lit/castle'
	to='kingclaudius@shakespeare.lit/castle'>
	<sxde xmlns='http://jabber.org/protocol/sxde'
	    xmlns:sxde='http://jabber.org/protocol/sxde#metadata'
	    session='abc123'
	    id='c1'>
		<negotiation>
			<in-session>851ba2</in-session>
		</negotiation>
	</sxde>
</message>

4.3.3 Connecting to a Session

To join an existing session the joiner MUST send a <connect-request/> element to the target JID.

Example 7. Connecting to an existing session

<message 
	 from='laertes@shakespeare.lit/castle'
	 to='kingclaudius@shakespeare.lit/castle'>
	<sxde xmlns='http://jabber.org/protocol/sxde'
	    xmlns:sxde='http://jabber.org/protocol/sxde#metadata'
	    session='851ba2'
	    id='e'>
		<negotiation>
			<connect-request />
		</negotiation>
	</sxde>
</message>

4.3.4 Offering to Send the State

An existing participant MUST offer the state of the session by sending a <state-offer/> element to the JID that sent the <connect-request/> element. The element MUST contain the <feature/> elements that were included in the original <connect-request/> or <state-offer/> element that the participant received.

Example 8. A participant offering to send the state

<message 
	from='kingclaudius@shakespeare.lit/castle'
	to='laertes@shakespeare.lit/castle'>
	<sxde xmlns='http://jabber.org/protocol/sxde'
	    xmlns:sxde='http://jabber.org/protocol/sxde#metadata'
	    session='851ba2'
	    id='f'>
		<negotiation>
			<state-offer>
				<feature var='http://jabber.org/protocol/whiteboard' />
			</state-offer>
		</negotiation>
	</sxde>
</message>

Example 9. The server component offering to send the state

<message 
	from='kingclaudius@shakespeare.lit/castle'
	to='laertes@shakespeare.lit/castle'>
	<sxde xmlns='http://jabber.org/protocol/sxde'
	    xmlns:sxde='http://jabber.org/protocol/sxde#metadata'
	    session='851ba2'
	    id='f'>
		<negotiation>
			<state-offer>
				<feature var='http://jabber.org/protocol/whiteboard' />
			</state-offer>
		</negotiation>
	</sxde>
</message>

4.3.5 Accepting a State Offer

In order to accept a state offer, the joining user MUST send <accept-state/> element to one of the entities that it received a <state-offer/> element from; usually the first one. The joiner MUST store all the <sxde/> elements it receives after the <state-offer/> element it decides to accept. It SHOULD also abort the negotiation with the other users that offered to send the state.

Once the other entity receives the <accept-state/> element it MUST proceed sending the history as described in "Sending the state".

Example 10. Accepting a state offer

		<message 
			 from='laertes@shakespeare.lit/castle'
			 to='kingclaudius@shakespeare.lit/castle'>
			<sxde xmlns='http://jabber.org/protocol/sxde'
			    xmlns:sxde='http://jabber.org/protocol/sxde#metadata'
			    session='851ba2'
			    id='g'>
				<negotiation>
					<accept-state/>
				</negotiation>
			</sxde>
		</message>
		

4.3.6 Sending the State of the Document.

The process of sending the state is following:

  1. The sender sends a <document-begin/> element and simultaneously takes a "snapshot" of the document's state.
  2. The sender sends the state as it was at the time of sending <document-begin/>.
  3. The sender sends a <document-end/> element which MUST also contains a <last-sxde/> element.
  4. The joiner applies all the <sxde/> elements that were received after the element indicated by the <last-sxde/> element.

The <last-sxde/> element MUST posess the attributes 'sender' and 'id' that specify the sender and the id of the last <sxde/> element which was included in the sent state.

The state can be sent in any number of <sxde/> elements but the user sending the state MUST NOT send any new <sxde/> elements between sending the <document-begin/> (i.e. taking the snapshot) and the <document-end/> element.

The state MUST include a version of each element that was definitely synchronized, and hence won't be undone, as well as all the later versions. In practice this can often be impossible to know in a session without a specialized MUC component so it may be safest to send version 0 and all the later edits to each element.

If there is a server component, it MUST also add additional attributes 'sxde:creator' and 'sxde:last-modified-by', that contain the JIDs of the creator and the last modifier, to each element when sending the state.

Example 11. Sending the state of an empty document

<message 
	from='kingclaudius@shakespeare.lit/castle'
	to='laertes@shakespeare.lit/castle'>
	<sxde xmlns='http://jabber.org/protocol/sxde'
	    xmlns:sxde='http://jabber.org/protocol/sxde#metadata'
	    session='851ba2'
	    id='b'>
		<negotiation>
			<document-begin/>
			<new>
				<whiteboard xmlns='http://jabber.org/protocol/whiteboard'
				     xmlns:sxde='http://jabber.org/protocol/sxde#metadata'
				     sxde:id='root'
				     z='0'/>
			</new>
			<document-end>
				<last-sxde sender=''
					   id=''/>
			</document-end>
		</negotiation>
		<new>
	</sxde>
</message>

Example 12. Sending the state of an existing document

<message 
	from='kingclaudius@shakespeare.lit/castle'
	to='laertes@shakespeare.lit/castle'>
	<sxde xmlns='http://jabber.org/protocol/sxde'
	    xmlns:sxde='http://jabber.org/protocol/sxde#metadata'
	    session='851ba2'
	    id='bxyz'>
		<negotiation>
			<document-begin/>
			<new>
				<whiteboard xmlns='http://jabber.org/protocol/whiteboard'
					    xmlns:sxde='http://jabber.org/protocol/sxde#metadata'
					    sxde:id='root'
					    z='0'/>
			</new>
			<new>
				<path sxde:id='1VDhmrCjj+B9j3/3mWj1B=='
				      sxde:z='3.2'
				      sxde:parent='root'
				      sxde:version='3'
				      d='M10 10L30 50L50 10Z'/>
			</new>
			<configure target='1VDhmrCjj+B9j3/3mWj1B=='
				version='4'>
				<attribute name='fill'>blue</attribute>
			</configure>
			<configure target='1VDhmrCjj+B9j3/3mWj1B=='
				   version='5'>
				<attribute name='stroke'>green</attribute>
				<attribute name='fill'>white</attribute>
			</configure>
			<new>
				<g sxde:id='n2nASm5H782gJKGbn5HUYT='
					sxde:z='0.432'
					sxde:parent='root'
					sxde:version='0'/>
			</new>
			<new>
				<circle sxde:id='nfsWd24NYvMa77m4fgs4bd5'
				      sxde:z='-15'
				      sxde:parent='n2nASm5H782gJKGbn5HUYT='
				      sxde:version='0'
				      cx='35'
				      cy='40'
				      r='7'/>
			</new>
			<configure target='1VDhmrCjj+B9j3/3mWj1B=='
				   version='1'>
				<parent>root</parent>
			</configure>
			<document-end>
				<last-sxde sender='kingclaudius@shakespeare.lit/castle'
					   id='abc'/>
			</document-end>
		</negotiation>
		<new>
	</sxde>
</message>

4.4 XML Document Requirements

The shared XML document MUST fulfill the following conditions:

  1. The root element of the document MUST possess the attributes 'xmlns:sxde' and 'sxde:id' with values "http://jabber.org/protocol/sxde#metadata" and "root" respectively. The values of these two attributes MUST NOT be changed during the session.
  2. Each element in the document MUST possess an 'sxde:id' attribute that contains a Globally Unique Identifier (GUID) and MUST NOT be changed the element has been created.
  3. Each element MUST possess an 'sxde:z' attribute.

Additionally, if an XML Schema Definition is specified for the document, all changes that result in a noncompliant document MUST be ignored (except for the version number increase in the case of element edits).

4.5 Element Edits and Commutative Edits

Changes to the document can be divided into two categories: commutative edits and element edits. Commutative edits are commutative with all edits and are never "undone" so keeping a history of them is NOT REQUIRED. Element edits are changes to a specific element and are always commutative with element edits that change a different element but not necessarily with changes to the same element. Hence their changes may need to be undone so keeping a history of the changes caused by element edits is REQUIRED. The breadth of this required history depends on the role of the entity and on whether the session works through a server component:

Table 3: Matrix of required history

By server By client
Server exists All element edits, that have not been undone, to elements that have not been removed; record of creator and last modifier of each element (to be included as 'sxde:creator' and 'sxde:last-modified-by' attributes in states sent to joining clients). Element edits sent by the client itself. May be removed once a further element edit to the same element from another entity is received.
Server does not exists --- All element edits, that have not been undone, to elements that have not been removed.

4.5.1 Requirements for the Server Component

The server MUST apply commutatative edits to its local copy like a client and pass on the edits without changes.

The server component intercepts and modifies element edits in order to reduce the history requirements of the clients as indicated above. Once it receives an element edit, it MUST take the following action depending on whether the version number of the edit is "in-order" (one higher than the current version) or "out-of-order":

  1. The server receives an in-order element edit: the server does not modify the edit, applies it locally, and passes it on normally.
  2. The server receives an out-of-order element edit: it processes the edit like a client would in order to locally undo conflicting edits; then, instead of passing on the out-of-order edit, the server replaces the edit by an in-order <configure/> element that results in an element identical to what the server has locally after the (possible) undos. Note that this <configure/> element may be empty.

4.6 Commutative Edits

4.6.1 Creating New Elements

A client can add a new element to the document by wrapping the element in a <new/> element. The element being added MUST posess the attributes 'sxde:id' and 'sxde:z' and MAY posess the attributes 'sxde:parent' and 'sxde:version'. The value of the 'sxde:id' attribute MUST be a Globally Unique Indentifier, which MAY be encoded to base64 for smaller size. The JID or the room nick of the user SHOULD be used in generation of the GUID.

Each element SHOULD also posess an attribute 'xmlns' with value the namespace of the target document.

Example 13. Sending new elements

<message 
	from='kingclaudius@shakespeare.lit/castle'
	to='laertes@shakespeare.lit/castle'>
	<sxde xmlns='http://jabber.org/protocol/sxde'
	    xmlns:sxde='http://jabber.org/protocol/sxde#metadata'
	    session='851ba2'
	    id='11'>
		<new>
			<circle xmlns='http://www.w3.org/2000/svg'
				sxde:id='1VDhmrCjj+B9j3/3mWj1B=='
				sxde:parent='MN554njlktBFK2q3D=='
				sxde:version='0'
				sxde:z='12'
				r='100'
				cx='300'
				cy='350'
				fill='green'
				stroke='red'
				stroke-width='6'/>
		</new>
		<new>
			<path xmlns='http://www.w3.org/2000/svg'
				sxde:id='n2nASm5H782gJKGbn5HUYT='
				sxde:parent='root'
				sxde:z='13.3'
				d='M100.0,100.0L300.0,125.0'
				stroke='blue'
				stroke-width='8'/>
		</new>
		<new>
			<circle xmlns='http://www.w3.org/2000/svg'
				sxde:id='nfsWd24NYvMa77m4fgs4bd5'
				sxde:z='16'
				r='100'
				cx='400'
				cy='400'
				fill='#000000'
				stroke='#7fab11'
				stroke-width='6'/>
		</new>
	</sxde>
</message> 

To process a <new/> element the client MUST store the child of the element as a child of the element specified by the 'parent' attribute or as a child of the root element if the 'parent' attribute doesn't exist. Each new child MUST be placed in the parent's tree immediately after the element that has the greatest z value but less than that of the child being added.

If the element being added posesses no 'sxde:z' or 'sxde:id' attribute or a value of the 'sxde:id' attribute identical to a value of the 'sxde:id' attribute of any existing element, the client MUST ignore the <new/> element.

The value of 'sxde:version' attribute defaults to zero if not specified.

4.6.2 Removing an Element

A client can remove any element that posesses a 'sxde:id' attribute, except the root element. It does it by sending a <remove/> element which MUST posess the attribute 'target'. The value of the attribute 'target' is the associated id value of the element to be removed.

Example 14. Removing an existing SVG element.

<message 
	from='kingclaudius@shakespeare.lit/castle'
	to='laertes@shakespeare.lit/castle'>
	<sxde xmlns='http://jabber.org/protocol/sxde'
	    xmlns:sxde='http://jabber.org/protocol/sxde#metadata'
	    session='851ba2'
	    id='13'>
		<remove target='15/kingclaudius@shakespeare.lit/castle'/>
		<remove target='14/kingclaudius@shakespeare.lit/castle'/>
	</sxde>
</message>

To processes a <remove/> element the client MUST remove the element that's specified by the 'target' attribute. However, all child elements of the target element, that posess a sxde:id attribute, MUST be inserted as children of the root element according to their indeces.

4.7 Element Edits

4.7.1 configure Element

The <configure/> element is used as a wrapper for all element edits. It MUST posess attributes 'target' and 'version' and MAY contain element edits. The value of the attribute 'target' is the id of the element to be modified. The value of the attribute 'version' is the current version of the element specified by the attribute 'target' incremented by one.

4.7.1.1 attribute Element

By including an <attribute/> element in a <configure/> element a client can set the value of any attribute of the element referred to by the 'target' attribute. The <attribute/> element MUST posess a 'name' attribute with a value equal to the name of the attribute to be set. The value of the specified attribute is replaced by the content of the <attribute/> element.

The <attribute/> element MAY also contain the attributes 'offset' and 'length' which MUST contain integer values. If both are specified and have values n and m respectively, only characters whose index is both larger than or equal to n and smaller than n + m are replaced by the the content of the <attribute/> element.

4.7.1.2 remove-attribute Element

By including a <remove-attribute/> element in a <configure/> element a client can remove any attribute of the element referred to by the 'target' attribute. The <attribute/> element MUST posess a 'name' attribute with a value equal to the name of the attribute to be removed.

4.7.1.3 content Element

This element MUST NOT be included in a <configure/> element whose target element is not a leaf node.

By including a <content/> element in a <configure/> element a client can set the content of the element specified by the 'target' attribute. The content is replaced by the content of the <content/> element.

4.7.1.4 parent Element

By including a <parent/> element in a <configure/> element a client can change the parent of the element referred to by the 'target' attribute. The element is moved so that it becomes a child of the element with an id equal to the the content of the <parent/> element. If no such element exists, the element becomes a child of the root element.

In any case, if the parent changes, the element MUST be inserted to its new position according to its z value value according to the same rule as with inserting new elements.

Example 15. Configure elements.

<message 
	from='kingclaudius@shakespeare.lit/castle'
	to='laertes@shakespeare.lit/castle'>
	<sxde xmlns='http://jabber.org/protocol/sxde'
	    xmlns:sxde='http://jabber.org/protocol/sxde#metadata'
	    session='851ba2'
	    id='14'>
		<configure target='15/kingclaudius@shakespeare.lit/castle'
			version='4'>
			<attribute name='stroke'>blue</attribute>
		</configure>
		<configure target='14/kingclaudius@shakespeare.lit/castle'
			version='1'>
			<attribute name='stroke-width'>4</attribute>
			<parent>3/laertes@shakespeare.lit/castle</parent>
		</configure>
		<configure target='18/kingclaudius@shakespeare.lit/castle'
			version='1'>
			<content>some <b>content</b> for the element</content>
			<remove-attribute name='font'/>
		</configure>
	</sxde>
</message>

4.7.2 Processing a Configure Element

To processes a <configure/> element the client MUST first increment the version of the element specified by the 'target' attribute by one. However, if the client is receiving history (i.e. edits sent between the <document-begin/> and <document-end/> elements), it MUST set the version of the target element to the value of the 'version' attribute. It MUST then compare whether this value is equal to the value of the 'version' attribute.

If the values are equal, the client MUST process the element edits contained in the <configure/> element.

If the values are not equal, the client MUST NOT further process the element. Additionally, if the version specified in the <configure/> element is smaller, the client MUST revert the effects of all the <configure/> elements that have the same value of the 'target' attribute and a value equal to or greater than the value of the 'version' attribute of the <configure/> element being processed.

If the element specified by the 'target' attribute has been removed, the client MUST NOT further process the element.

Note that in any case the version of the element remains changed.

4.7.3 Changing the Order of Elements

A client can change the position of any element in its parent's tree of children by changing the value of the 'sxde:z' attribute.

Once such a value is changed, the client MUST place the element in its new position according to the rule used for placing new elements.

5. Implementation Notes

It should be noted that given the MUC specification and the requirement of this protocol to send a connect request message to all room members in order to join an existing session, you effectively can not use the visitor role of MUC with a regular MUC server component. However, the specialized MUC component, if used, MUST accept and respond to the connection requests even if they come from users who do not have voice in the room.

6. Security Considerations

7. IANA Considerations

This XEP requires no interaction with the Internet Assigned Numbers Authority (IANA).

8. Jabber Registrar Considerations

8.1 Protocol Namespaces

The &REGISTRAR; shall include 'http://jabber.org/protocol/sxde' in its registry of protocol namespaces.

8.2 Service Discovery Identities

The &REGISTRAR; shall add the type of "sxde" to the "collaboration" category in its registry of service discovery identities.

9. XML Schema


<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
	xmlns='http://jabber.org/protocol/sxde' 
	xmlns:xs='http://www.w3.org/2001/XMLSchema' 
	targetNamespace='http://jabber.org/protocol/sxde' 
	elementFormDefault='qualified'>

	<xs:annotation>
		<xs:documentation>
			The protocol documented by this schema is defined in
			XEP-xxxx: http://www.jabber.org/XEPs/XEP-xxxx.html
		</xs:documentation>
	</xs:annotation>


</xs:schema>

	

10. Acknowledgements

The theory behind the synchronization of element edits was put forward by Mats Bengtsson (http://coccinella.sourceforge.net/docs/MemoSyncSVG-XMPP.txt). I would also like to thank him for countless emails he exchanged with me about regarding methods described in this XEP.

Dale Harvey also provided valuable input.


Notes


Revision History

Version 0.0.3 (2006-01-09)

(jg)

Version 0.0.2 (2006-08-28)

Initial version of the SXdE proposal after splitting the previous whiteboarding proposal.

(jg)

Version 0.0.1 (2006-06-19)

Initial version.

(jg)


END