<abstract>This specification defines a protocol that enables two or more endpoints to collaboratively edit an XML object. The protocol is intended for use mainly over the Extensible Messaging and Presence Protocol (XMPP), either by existing instant messaging clients or by specialized editing clients. However, the protocol could also be used over a direct TCP connection rather than over XMPP.</abstract>
<remark><p>Updated Jingle namespaces, transport definitions, reason codes, and other syntax; improved feature discovery and session advertisement; updated namespace to be urn:xmpp:sxe:0 for future-compatibility.</p></remark>
</revision>
<revision>
<version>0.0.9</version>
<date>2009-12-04</date>
<initials>psa</initials>
<remark><p>Added session signalling via presence.</p></remark>
</revision>
<revision>
<version>0.0.8</version>
<date>2008-01-29</date>
<initials>psa/jg</initials>
<remark>
<ul>
<li>Modified negotiation protocol to use Jingle.</li>
<li>Defined Jingle transport method.</li>
</ul>
</remark>
</revision>
<revision>
<version>0.0.7</version>
<date>2008-01-24</date>
<initials>jg</initials>
<remark>
<ul>
<li>Added the "Example Session" section.</li>
<li>Clarification of the 'last-sender' and 'last-id' attributes.</li>
<li>Changed the definition of the "state".</li>
<li>Changed "SHOULD [abort the negotiation with others who offered the state]" to a "MUST" after one offer has been accepted.</li>
</ul>
</remark>
</revision>
<revision>
<version>0.0.6</version>
<date>2008-01-20</date>
<initials>jg</initials>
<remark>
<ul>
<li>Wording changes.</li>
<li>Added a paragraph about "maintaining an unordered set of records" to the introduction.</li>
<li>Renamed "node id" to "record id".</li>
<li>Renamed "metadata" to "record".</li>
<li>Renamed <configure/> to <set/>.</li>
<li>Renamed "node edits" to non-commutative edits.</li>
<li>Simplified the explanation of processing edits by creating a section "Mapping the Records to the DOM Document" and concentrating on the changes to the records in section "Commutative and Non-commutative edits".</li>
<li>Added the description of the <prolog/> element.</li>
<li>Replaced the <last-sxde/> element with 'last-sender' and 'last-id' attributes.</li>
<li>Added the 'replacefrom' and 'replacen' attributes.</li>
<li>Replaced the <in-session/> element with the <alternative-session/> element.</li>
</ul>
</remark>
</revision>
<revision>
<version>0.0.5</version>
<date>2007-08-30</date>
<initials>jg</initials>
<remark>
<ul>
<li>Renamed 'z' to 'weight'.</li>
<li>Moved the metadata (node id, primary-weight) out of the DOM. I.e. they are no longer attributes of elements; it is up to the implementation to how the metadata is stored.</li>
<li>Changed "element edits" to "node edits". Now each DOM node is required to have a GUID and can be modified separately. All nodes are arranged by their weight which removes the previous problems with mixed content.</li>
<li>Modified the examples accordingly.</li>
<li>Improved the glossary definitions.</li>
</ul>
</remark>
</revision>
<revision>
<version>0.0.4</version>
<date>2007-03-26</date>
<initials>jg</initials>
<remark><p>Wording changes. Changes to how set content/move element conflict is handled.</p></remark>
</revision>
<revision>
<version>0.0.3</version>
<date>2007-01-09</date>
<initials>jg</initials>
<remark>
<ul>
<li>Simplified the process for joining a session. Removed the notion of history being different from state in the context of joining.</li>
<li>Moved responsibility of undoing other users' conflicting edits to the server if one exists.</li>
<li>Added that changes should be checked against the XSD of the document.</li>
<li>Renamed 'hash' attribute as 'id'.</li>
<li>Changed the format of the <feature/> elements.</li>
<li>Modified negotiation abortion reason.</li>
<li>Removed the XSD for now.</li>
<li>Removed the "Security Considerations" for now.</li>
<li>JEP to XEP.</li>
</ul>
</remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2006-08-28</date>
<initials>jg</initials>
<remark><p>Initial version of the SXdE proposal after splitting the previous whiteboarding proposal.</p></remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2006-06-19</date>
<initials>jg</initials>
<remark><p>Initial version.</p></remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>This specification defines a protocol for collaboratively editing XML data. Essentially, this protocol provides a simple way of synchronizing an unordered set of records across several endpoints. Additionally, this protocol defines a mapping between such a set of records and the Document Object Model (DOM).</p>
<p>A special feature of this protocol compared to most other collaborative editing tools is that no master or server entity is required. A &xep0045; component or specialized editing component can be used for sessions that have a large number of participants, that need to be persistent, or that require more granular access control. However, the client implementation is minimally different whether such a specialized component is used or whether the session is one-to-one or multi-user.</p>
</section1>
<section1topic='Requirements'anchor='reqs'>
<p>Requirements for shared editing are provided in &xep0228;.</p>
</section1>
<section1topic='Glossary'anchor='glossary'>
<p>GUID: a Globally Unique Indentifier, used as the identifier for a shared editing session.</p>
<p>Host: The JID to which the SXE messages are sent for relaying to other members of the session; this can be the initiator of the session (e.g., in a one-to-one session or small multi-user session) or a multi-user chat room or specialized shared editing component.</p>
<p>RID: the Record ID given to a record when it is created.</p>
<p>State: In the context of a new user joining, the state refers to the set of records that describes the edited object, including all previous versions of each record. All entities involved in the session are REQUIRED to keep this state unless a specialized component handles user joins.</p>
<p>Weight: Primarily, the weight of a node is represented by the 'primary-weight' field of the corresponding record. Secondarily, if the values of the 'primary-weight' of two records are equal, the first differing characters of the rids are compared by their Unicode values. The higher the character the higher the weight of the node is.</p>
<p>When used in the context of XMPP, Shared XML Editing relies on &xep0166; for overall session management. In Jingle terms, SXE defines a "transport method" that can be used for multiple "application types" such as XHTML documents, SVG whiteboards, &xep0204;, or any other XML data format.</p>
<p>In order to initiate a shared editing session, one party sends a Jingle session-initiate request to another party. Here the <transport/> element indicates support for exchanging SXE information over XMPP and the <description/> element indicates support for editing of XHTML documents (this application type has not been defined yet and is used here only as an example). The <transport/> element MUST include at least one <host/> element that specifies the entity that serves as the host for the session. The host can be the initiator of the session (and must be for a one-to-one session) or a multi-user chat room or specialized reflector where the session is hosted.</p>
<p>The responder indiciates the reason for refusing the session by including a "reason" element. The following reasons are suggested (see also <cite>XEP-0166</cite>):</p>
<ul>
<li>alternative-session -- the responder already has an active session with the initiator and wishes to use that session instead.</li>
<li>decline -- the responder formally declines the session.</li>
<li>unsupported-applications -- the responder supports none of the offered the application types.</li>
</ul>
<p>The initiator immediately acknowledges receipt of the session-terminate.</p>
<section1topic='Determining the features of the Host'anchor='host'>
<p>Before connecting to a session, a party MUST determine the &xep0030; identity and supported features of the host. In many situations the party already knows this information (e.g., if the host is the initiator of the Jingle session). In other situations the party will need to send a service discovery information request to the host.</p>
<p>Such presence can be broadcast or can be sent in the context of a multi-user chat room (see <cite>XEP-0045</cite>).</p>
<p>However, presence is not sent when operating in a serverless messaging environment (see <cite>XEP-0174</cite>). Instead, DNS TXT records are published. Two new key-value pairs are used to advertise a session id ("sxe_id") and session name ("sxe_name") when using serverless messaging.</p>
</section1>
<section1topic='Connecting to a Session'anchor='connect'>
<p>In order to synchronize its local state with the existing state of the edited object, an entity sends a connection request to the host. The identity learned through service discovery determines what kind of message the joining party sends (e.g., type='groupchat' if the host is a MUC room).</p>
<p>To connect to a session, the joiner MUST send an SXE <connect/> element to the host.</p>
<examplecaption='Connecting to a session'><![CDATA[
<p>When a joining user sends a connect request, the joiner must retrieve the state of the session from an existing participant. The following ruules apply:</p>
<ol>
<li>In a one-to-one session, the initiator MUST offer to send the state.</li>
<li>In a multi-user session, both the host and the invitor (initiator) MUST offer to send the state. However, other participants MAY offer to send the state. The joiner SHOULD prefer to receive the state from the host or initiator.</li>
</ol>
<p>The state offer MUST contain the <description/> element or elements that were included in the Jingle session-initiate request.</p>
<p>The joiner accepts a state offer by sending an <accept-state/> element to one of the entities that offer to send the state. The joiner MUST store all the <sxe/> elements it receives after the <state-offer/> element it decides to accept. It MUST also abort the negotiation with the other users that offered to send the state.</p>
<p>Once the other entity receives the <accept-state/> element it MUST proceed sending the state as described in the next section.</p>
<examplecaption='Accepting a state offer'><![CDATA[
<section2topic='Sending the State of the Document'>
<p>The process of sending the state is following:</p>
<ol>
<li>The sender sends a <document-begin/> element and simultaneously takes a "snapshot" of the document's state. The <document-begin/> element SHOULD have a 'prolog' attribute. The 'prolog' attribute should contain the XML prolog of the document encoded using the data: URI scheme (RFC 2397).</li>
<li>The sender sends the state as it was at the time of sending <document-begin/>.</li>
<li>The sender sends a <document-end/> element.</li>
</ol>
<p>The state can be sent in any number of <sxe/> elements but the user sending the state MUST NOT send any new <sxe/> elements between sending the <document-begin/> (i.e. taking the snapshot) and the <document-end/> element.</p>
<p>The state SHOULD include a version of each element that was 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. Version 0 is implied if the version element is missing.</p>
<examplecaption='Sending the state of a blank document (only prolog)'><![CDATA[
<p>All SXE elements MUST be contained in a <sxe/> element. This element MUST posess the following attributes:</p>
<tablecaption="Attributes of <sxe/> element">
<tr>
<th>Attribute</th>
<th>Description</th>
</tr>
<tr>
<td>xmlns</td>
<td>REQUIRED and MUST be "urn:xmpp:sxe:0"</td>
</tr>
<tr>
<td>session</td>
<td>REQUIRED and MUST be a GUID of the session.</td>
</tr>
<tr>
<td>id</td>
<td>REQUIRED and MUST be unique within the set of <sxe/> elements sent by the user to the session.</td>
</tr>
</table>
</section2>
<section2topic="XML Document Requirements">
<p>The prolog of the XML document cannot be edited after the session has been established.</p>
<p>If an XML Schema Definition is specified for the document and the processing of an <sxe/> element results in a noncompliant document, the receiving client SHOULD reply with edits that effectively undo the offending edits. TODO: the offending client should probably be notified.</p>
</section2>
<section2topic="Mapping the Records to the DOM Document">
<p>A record contains the following fields and corresponds to a single DOM node:</p>
<tablecaption='The fields of a record'>
<tr>
<th>Field Name</th>
<th>Mutable</th>
<th>Applies to nodes of type</th>
<th>Description</th>
</tr>
<tr>
<td>rid</td>
<td>no</td>
<td>all</td>
<td>The GUID of the record.</td>
</tr>
<tr>
<td>type</td>
<td>no</td>
<td>all</td>
<td>The type of DOM node (element, attr, etc.).</td>
</tr>
<tr>
<td>version</td>
<td>Indirectly</td>
<td>all</td>
<td>The current version of the record.</td>
</tr>
<tr>
<td>parent</td>
<td>yes</td>
<td>all</td>
<td>The record id of the record corresponding to the parent node.</td>
</tr>
<tr>
<td>primary-weight</td>
<td>yes</td>
<td>all</td>
<td>The primary weight used to determine the order of sibling nodes corresponding to the records.</td>
</tr>
<tr>
<td>ns</td>
<td>yes (TODO: is this reasonable?)</td>
<td>element, attr</td>
<td>The namespace of the element or attribute</td>
</tr>
<tr>
<td>name</td>
<td>yes (TODO: is this reasonable?)</td>
<td>element, attr</td>
<td>The name of the element or attribute.</td>
</tr>
<tr>
<td>chdata</td>
<td>yes</td>
<td>text, attr, comment</td>
<td>The content of a text node or a comment or the value of the attribute.</td>
</tr>
<tr>
<td>pitarget</td>
<td>yes (TODO: is this reasonable?)</td>
<td>proccessinginstruction</td>
<td>The target of the processing instruction.</td>
</tr>
<tr>
<td>pidata</td>
<td>yes</td>
<td>proccessinginstruction</td>
<td>The data of the processing instruction.</td>
</tr>
</table>
<p>Whenever a record is added, modified, or removed, the client MUST ensure that the DOM nodes corresponding to the records meet the following criteria:</p>
<ol>
<li>The parent of each DOM node MUST be the node corresponding to the record specified by the 'record id' field of the record of the node. If no such record exists, the "orphan" record MUST be deleted. If the 'parent' field is empty, the node corresponding to the record MUST be a child of the DOM document itself. If two root nodes exist, the record with lower secondary weight MUST be removed. </li>
<li>Each node MUST be located after the child node that has the greatest weight less than the weight of the node.</li>
<li>The namespace of each DOM element and attribute MUST be equal to the 'name' field of the corresponding record.</li>
<li>The name of each DOM element and attribute MUST be equal to the 'name' field of the corresponding record. If two records for attribute nodes specify the same 'name' and 'parent', the record with lower secondary weight MUST be removed.</li>
<li>The value of each DOM attribute node MUST be equal to the 'chdata' field of the corresponding record.</li>
<li>The content of each DOM text node MUST be equal to the 'chdata' field of the corresponding record.</li>
<li>The content of each DOM comment node MUST be equal to the 'chdata' field of the corresponding record.</li>
<li>The target of each DOM processing instruction MUST be equal to the 'pitarget' field of the corresponding record.</li>
<li>The data of each DOM processing instruction MUST be equal to the 'pidata' field of the corresponding record.</li>
<li>The DOM nodes do not offend the XML Schema. If they do, the client SHOULD send edits to correct the situation.</li>
</ol>
<tablecaption='Example set of records'>
<tr>
<th>rid</th>
<th>type</th>
<th>version</th>
<th>parent</th>
<th>primary-weight</th>
<th>ns</th>
<th>name</th>
<th>chdata</th>
<th>pitarget</th>
<th>pidata</th>
</tr>
<tr>
<td>GUID0</td>
<td>element</td>
<td>0</td>
<td></td>
<td>0</td>
<td>http://www.w3.org/2000/svg</td>
<td>svg</td>
<td>N/A</td>
<td>N/A</td>
<td>N/A</td>
</tr>
<tr>
<td>GUID1</td>
<td>element</td>
<td>0</td>
<td>GUID0</td>
<td>0</td>
<td></td>
<td>path</td>
<td>N/A</td>
<td>N/A</td>
<td>N/A</td>
</tr>
<tr>
<td>GUID2</td>
<td>attr</td>
<td>0</td>
<td>GUID1</td>
<td>0</td>
<td></td>
<td>d</td>
<td>M10 10L20 20L20 10Z</td>
<td>N/A</td>
<td>N/A</td>
</tr>
<tr>
<td>GUID9</td>
<td>element</td>
<td>0</td>
<td>GUID0</td>
<td>3.4</td>
<td></td>
<td>g</td>
<td>N/A</td>
<td>N/A</td>
<td>N/A</td>
</tr>
<tr>
<td>GUID5</td>
<td>element</td>
<td>0</td>
<td>GUID0</td>
<td>3.4</td>
<td></td>
<td>circle</td>
<td>N/A</td>
<td>N/A</td>
<td>N/A</td>
</tr>
<tr>
<td>GUID6</td>
<td>attr</td>
<td>3</td>
<td>GUID5</td>
<td>0</td>
<td></td>
<td>cx</td>
<td>10</td>
<td>N/A</td>
<td>N/A</td>
</tr>
<tr>
<td>GUID7</td>
<td>attr</td>
<td>1</td>
<td>GUID5</td>
<td>1</td>
<td></td>
<td>cy</td>
<td>20</td>
<td>N/A</td>
<td>N/A</td>
</tr>
<tr>
<td>GUID8</td>
<td>attr</td>
<td>0</td>
<td>GUID5</td>
<td>2</td>
<td></td>
<td>r</td>
<td>5</td>
<td>N/A</td>
<td>N/A</td>
</tr>
</table>
<examplecaption='Corresponding XML document (without the XML prolog)'><![CDATA[
<svgxmlns='http://www.w3.org/2000/svg'>
<pathd='M10 10L20 20L20 10Z'/>
<circlecx='10'cy='20'r='5'/>
<g/>
</svg>
]]></example>
</section2>
<section2topic='Commutative and Non-commutative Edits'>
<p>Changes to the records can be divided into two categories: commutative and non-commutative edits.</p>
<p>Commutative edits are commutative with all edits and are never "undone" so keeping a history of them is NOT REQUIRED. Edits that add or remove records are commutative.</p>
<p>An edit that changes an existing record is called non-commutative because it may not be commutative with edits that change the same record. Hence these changes may need to be undone so keeping a history of the changes caused by such 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:</p>
<td>All non-commutative edits, that have not been undone to records that have not been removed; must store the creator and last modifier of each node (to be included as 'creator' and 'last-modified-by' attributes in <new/> elements sent to joining clients).</td>
<td>Non-commutative edits sent by the client itself. May be removed once a further non-commutative edits to the same record from another entity is received.</td>
</tr>
<tr>
<th>Server does not exists</th>
<td>---</td>
<td>All non-commutative edits, that have not been undone, to records that have not been removed.</td>
</tr>
</table>
<section3topic='Requirements for the Server Component'anchor='serverrequirements'>
<p>The server MUST apply commutatative edits to its local copy like a client and pass on the edits without changes.</p>
<p>The server component intercepts and modifies non-commutative edits in order to reduce the history requirements of the clients as indicated above. Once it receives a non-commutative 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":</p>
<ol>
<li>The server receives an in-order non-commutative edit: the server does not modify the edit, applies it locally, and passes it on normally.</li>
<li>The server receives an out-of-order non-commutative 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 non-commutative edit that results in a record identical to what the server has locally after the (possible) undos. Note that this edit may be a "no-op" that merely increases the version of the target.</li>
<p>A client MUST NOT send a <remove/> element that removes a node that has child nodes without explicitly removing the records of those nodes first.</p>
<examplecaption='Removing an existing nodes.'><