<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>Initial published version.</p></remark>
</revision>
<revision>
<version>0.0.10</version>
<date>2010-06-08</date>
<initials>tp/psa</initials>
<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 central 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>
<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'><