JEP-xxxx: SVG Whiteboarding

This JEP defines a protocol that allows clients to share a common whiteboard.


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 a Jabber Enhancement Proposal (JEP). If this document is accepted as a JEP by the Jabber Council, it will be published at <http://www.jabber.org/jeps/> and announced on the <standards-jig@jabber.org> mailing list.


JEP Information

Status: ProtoJEP
Type: Standards Track
Number: xxxx
Version: 0.0.1
Last Updated: 2006-06-19
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, XMPP IM
Supersedes: JEP-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 JEP 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 Whiteboard Abilities
4.2. The wb element
4.3. Initiating a New Whiteboard Session
4.3.1. Invitation
4.3.2. Aborting the negotiation
4.3.3. Accepting the invitaion
4.3.4. Sending the history.
4.3.5. Connecting to an existing session
4.3.6. Offering to send the history
4.3.7. Accepting a history offer
4.4. Element edits and commutative edits
4.5. Commutative edits
4.5.1. Creating New SVG Elements
4.5.1.1. Sending
4.5.1.2. Processing
4.5.2. Changing the Stacking Order of the Elements
4.5.2.1. Sending
4.5.2.2. Processing
4.5.3. Removing an Element
4.5.3.1. Sending
4.5.3.2. Processing
4.6. The Element Edits
4.6.1. The configure element
4.6.2. Processing a configure element
4.6.3. The attribute element
4.6.4. The content element
4.6.5. The parent element
5. Business Rules
6. Implementation Notes
7. Security Considerations
8. IANA Considerations
9. Jabber Registrar Considerations
9.1. Protocol Namespaces
9.2. Service Discovery Identities
10. XML Schema
11. Acknowledgements
Notes
Revision History


1. Introduction

The obsolete &jep0010; states: "Jabber is often thought of simply as a system for instant messaging, albeit an open one. However, Jabber technology can be used, and is being used, in applications quite different from simple IM. One of these applications is whiteboarding. In collaborative work, the ability to draw (for example, to design sketches, UML schemas, house architectures, and organizational plans) is essential, as exemplified by the success of real-world whiteboarding applications such as Microsoft NetMeeting. Whiteboarding can also be used for entertainment purposes such as games and quizzes. Because of the value of whiteboarding as an important real-time collaboration tool, other IM services are beginning to offer these capabilities. For these and other reasons, I believe that a good protocol for whiteboarding in Jabber would be of great value".

The deferred &jep0113; states: "The increasing penetration of pen-based devices, such as PDAs and tablet PCs, makes the need for a protocol that allows for sending freehand drawing information more urgent".

JEP-0113: Whiteboarding also states "Several attempts have been made to create a whiteboarding protocol for Jabber..." and goes on listing several of these. However, they all fail to fulfill the following criteria:

2. Requirements

  1. The protocol must allow for sharing of freehand drawing on a common whiteboard.
  2. The protocol should allow including images in common formats.
  3. The protocol should allow including foreign object that each client MAY interpret.
  4. Each client MUST have identical copies of the common whiteboard given the same packages have been received and correct implementation of the protocol.
  5. The protocol should be simple to implement. Furthermore, the protocol should specify that each client should fully implement only the interpreting of the incoming messages. The protocol should allow clients to choose which outgoing messages to implement.
  6. The protocol should be light-weight where that doesn't unproportionetely complicate the implementation.

3. Glossary

An elements associated id value: the value of the 'id' attribute posessed by the <new/> element that the element was contained in when it was added.

Index of an element: Primarily, the index of an element is represented by the value of the 'index' attribute posessed by the <new/> element that the element was contained in when it was added. The value of this primary part of the index may be changed by <move/> elements. Secondarily, if the values of the index 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 index of the element.

4. Use Cases

4.1 Querying Whiteboard Abilities

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

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 whiteboarding protocol, it MUST return a feature of "http://jabber.org/protocol/svgwb":

Example 2. Service discovery request

<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/svgwb'/>
    ...
  </query>
</iq>

4.2 The wb element

All whiteboard messages MUST be contained in a <wb/> element which MUST posess the attributes 'xmlns', which specifies the http://jabber.org/protocol/svgwb as the namespace, 'session', which MUST be a unique identifier for the session, and 'hash', which MUST contain data that is unique in the set of <wb/> elements sent by the user.

Example 3. Initiating a new session

<message 
        from='kingclaudius@shakespeare.lit/castle'
        to='laertes@shakespeare.lit/castle'
        type='chat'>
        <wb xmlns='http://jabber.org/protocol/svgwb'
            session='851ba2'
            hash='a'>
                [whiteboard messages]
        </wb>
</message>

4.3 Initiating a New Whiteboard 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 accept or abort this negotiation on their part.
  3. If one or more receivers accepted the invitation, the sender sends the initial document history to the receivers.
  4. Session established. The document is ready to be modified by all users.

The process for joining an existing session:

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

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

Also note that all of the negotiation messages, excluding the history, MUST be contained in a <protocol/> element.

4.3.1 Invitation

To invite users to a session the initiator MUST send an <invitation/> element to the target JID. The element SHOULD contain <feature/> elements which contain feature strings specified by the SVG specification.

The initiator of the session may choose to abort the negotiation based on the replies the invitation receives. For example, the initiator may choose to abort the current negotiation and start a new one with different features that are supported by more of the peers.

Example 4. Invitation to a new session

<message 
        from='kingclaudius@shakespeare.lit/castle'
        to='laertes@shakespeare.lit/castle'>
        <wb xmlns='http://jabber.org/protocol/svgwb'
            session='851ba2'
            hash='b'>
                <protocol>
                        <invitation>
                                <feature>http://www.w3.org/TR/SVG11/feature#CoreAttribute</feature>
                                <feature>http://www.w3.org/TR/SVG11/feature#BasicStructure</feature>
                                <feature>http://www.w3.org/TR/SVG11/feature#BasicPaintAttribute</feature>
                                <feature>http://www.w3.org/TR/SVG11/feature#Shape</feature>
                        </invitation>
                </protocol>
        </wb>
</message>

4.3.2 Aborting the 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.

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 1: 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.
peer-already-in-session This element MAY be included if the peer is already in session and does not support multiple concurrent sessions. Additionally the element MAY contain a session ID that the peer can join.

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

<message 
        from='laertes@shakespeare.lit/castle'
        to='kingclaudius@shakespeare.lit/castle'>
        <wb xmlns='http://jabber.org/protocol/svgwb'
            session='851ba2'
            hash='c'>
                <protocol>
                        <abort-negotiation>
                                <supported-features>
                                        <feature>http://www.w3.org/TR/SVG11/feature#CoreAttribute</feature>
                                        <feature>http://www.w3.org/TR/SVG11/feature#BasicStructure</feature>
                                        <feature>http://www.w3.org/TR/SVG11/feature#Shape</feature>
                                </supported-features>
                        </abort-negotiation>
                </protocol>
        </wb>
</message>

Example 6. Backing out from a negotiation because the user is already in session

<message 
        from='laertes@shakespeare.lit/castle'
        to='kingclaudius@shakespeare.lit/castle'>
        <wb xmlns='http://jabber.org/protocol/svgwb'
            session='851ba2'
            hash='c14'>
                <protocol>
                        <abort-negotiation>
                                <peer-already-in-session>3bf4</peer-already-in-session>
                        </abort-negotiation>
                </protocol>
        </wb>
</message>

4.3.3 Accepting the invitaion

If a user receives an <invitation/> element and wishes to join the session, the user MUST reply with an <accept-invitation/> element.

Example 7. Accepting an invitation

<message 
        from='laertes@shakespeare.lit/castle'
        to='kingclaudius@shakespeare.lit/castle'>
        <wb xmlns='http://jabber.org/protocol/svgwb'
            session='851ba2' 
            hash='d'>
                <protocol>
                        <accept-invitation/>
                </protocol>
        </wb>
</message>

4.3.4 Sending the history.

The process of sending the history is three-fold:

  1. The sender sends a <document-begin/> element and simultaneously takes a "snapshot" of the document history.
  2. The sender sends the history as it was at the time of sending <document-begin/>.
  3. The sender sends a <document-end/> element which MUST also contains a <last-wb/> element.

The <last-wb/> element MUST posess the attributes 'sender' and 'hash' that specify the sender and the hash of the last <wb/> element which was included in the history snapshot.

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

The history MUST include a version of each element that was definitely synchronized, and hence won't be undone, as well as all the later versions.

Example 8. Sending the state of an empty document

<message 
        from='kingclaudius@shakespeare.lit/castle'
        to='laertes@shakespeare.lit/castle'>
        <wb xmlns='http://jabber.org/protocol/svgwb'
            session='851ba2'
            hash='b'>
                <protocol>
                        <document-begin/>
                </protocol>
                <protocol>
                        <document-end>
                                <last-wb sender=''
                                           hash=''/>
                        </document-end>
                </protocol>
                <new>
        </wb>
</message>

Example 9. Sending the state of an existing document

<message 
        from='kingclaudius@shakespeare.lit/castle'
        to='laertes@shakespeare.lit/castle'>
        <wb xmlns='http://jabber.org/protocol/svgwb'
            session='851ba2'
            hash='bxyz'>
                <protocol>
                        <document-begin/>
                </protocol>
                <new id='3/kingclaudius@shakespeare.lit/castle' index='3.2' version='3'>
                        <path d='M10 10L30 50L50 10Z'/>
                </new>
                <configure target='3/kingclaudius@shakespeare.lit/castle'
                           version='4'
                           attribute='stroke'
                           value='blue'>
                <protocol>
                <protocol>
                        <document-end/>
                                <last-wb sender='kingclaudius@shakespeare.lit/castle'
                                           hash='abc'/>
                </protocol>
                <new>
        </wb>
</message>

4.3.5 Connecting to an existing session

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

Example 10. Connecting to an existing session

<message 
        from='kingclaudius@shakespeare.lit/castle'
        to='laertes@shakespeare.lit/castle'>
        <wb xmlns='http://jabber.org/protocol/svgwb'
            session='851ba2'
            hash='e'>
                <protocol>
                        <connect-request/>
                </protocol>
        </wb>
</message>

4.3.6 Offering to send the history

An existing participant SHOULD offer the history of the session by sending a <history-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 <history-offer/> element that the participant received.

Example 11. Offering to send the history

<message 
        from='kingclaudius@shakespeare.lit/castle'
        to='laertes@shakespeare.lit/castle'>
        <wb xmlns='http://jabber.org/protocol/svgwb'
            session='851ba2'
            hash='f'>
                <protocol>
                        <history-offer>
                                <feature>http://www.w3.org/TR/SVG11/feature#CoreAttribute</feature>
                                <feature>http://www.w3.org/TR/SVG11/feature#BasicStructure</feature>
                                <feature>http://www.w3.org/TR/SVG11/feature#BasicPaintAttribute</feature>
                                <feature>http://www.w3.org/TR/SVG11/feature#Shape</feature>
                        </history-offer>
                </protocol>
        </wb>
</message>

4.3.7 Accepting a history offer

In order to join the session, the joining user MUST send <accept-history/> element to one of the users that it received a <history-offer/> element from. It SHOULD also abort the negotiation with the other users that offered to send the history.

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

Example 12. Accepting a history offer

<message 
        from='kingclaudius@shakespeare.lit/castle'
        to='laertes@shakespeare.lit/castle'>
        <wb xmlns='http://jabber.org/protocol/svgwb'
            session='851ba2'
            hash='g'>
                <protocol>
                        <accept-history>
                </protocol>
        </wb>
</message>

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

4.5 Commutative edits

4.5.1 Creating New SVG Elements

4.5.1.1 Sending

A client can add a new SVG element to the document by wrapping the element in a <new/> element. The <new/> element MUST posess the attributes 'id' and 'index' and MAY posess the attributes 'parent' and 'version'. It MUST also contain exactly one SVG element of the negotiated profile and version. The value of the 'id' attribute MUST be of the form "m/JID/resource" where "JID/resource" MUST be the senders "full JID" or the nick in the MUC and "m" MUST be such that the 'id' is unique within the session.

Each SVG element SHOULD also posess an attribute 'xmlns' with value "http://www.w3.org/2000/svg" though it MUST not change the interpretation of the receiver even if not included.

Example 13. Sending new SVG elements

<message 
        from='kingclaudius@shakespeare.lit/castle'
        to='laertes@shakespeare.lit/castle'>
        <wb xmlns='http://jabber.org/protocol/svgwb'
            session='851ba2'
            hash='11'>
                <new id='14/kingclaudius@shakespeare.lit/castle'
                index='12'>
                        <circle xmlns='http://www.w3.org/2000/svg'
                                r='100'
                                cx='300'
                                cy='350'
                                fill='green'
                                stroke='red'
                                stroke-width='6'/>
                </new>
                <new id='15/kingclaudius@shakespeare.lit/castle'>
                index='15'>
                        <path xmlns='http://www.w3.org/2000/svg'
                                d='M100.0,100.0L300.0,125.0'
                                stroke='blue'
                                stroke-width='8'/>
                </new>
                <new id='16/kingclaudius@shakespeare.lit/castle'
                index='16'>
                        <circle xmlns='http://www.w3.org/2000/svg'
                                r='100'
                                cx='400'
                                cy='400'
                                fill='#000000'
                                stroke='#7fab11'
                                stroke-width='6'/>
                </new>
        </wb>
</message> 

4.5.1.2 Processing

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 <svg/> 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 index of the element but less than that of the child being added.

The client must store the association between the added SVG element and the value of the 'id' attribute of the <new/> element so that <configure/>, <move/> and <remove/> elements that have this value in their 'target' attribute are applied to this element. Similarly, the client must store the association between the added SVG element and the value of the 'index' attribute.

If the <new/> element posesses no 'id' attribute or a value of the 'id' attribute identical to a value of the 'id' attribute of any previous <new/> element, the client MUST ignore the <new/> element.

The client must also store version information of each element. All new elements have version 0 unless otherwise specified by the 'version' attribute.

4.5.2 Changing the Stacking Order of the Elements

4.5.2.1 Sending

A client can change the position of any element in its parent's tree of children. It does it by sending a <move/> element which MUST posess the attributes 'target' and 'di'. The value of the attribute 'target' is the associated id value of the element to be moved. The value of the attribute 'di' is the desired change to the index of the target element (in relative terms).

Example 14. Changing the stacking order of existing SVG elements.

<message 
        from='kingclaudius@shakespeare.lit/castle'
        to='laertes@shakespeare.lit/castle'>
        <wb xmlns='http://jabber.org/protocol/svgwb'
            session='851ba2'
            hash='12'>
                <move target='15/kingclaudius@shakespeare.lit/castle'
                      di='-3.2'/>
                <move target='14/kingclaudius@shakespeare.lit/castle'
                      di='1'/>
        </wb>
</message>

4.5.2.2 Processing

To processes a <move/> element the client MUST add the value of the 'di' attribute to the primary part of the index of the element specified by the 'target' attribute. The element MUST then be placed again in its parent's tree of children so that it's immediately after the element with the greatest index which is less than that of the element being placed.

4.5.3 Removing an Element

4.5.3.1 Sending

A client can remove any element that posesses an 'id' attribute. 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 15. Removing an existing SVG element.

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

4.5.3.2 Processing

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 MUST be inserted as children of the root element according to their indeces.

4.6 The Element Edits

4.6.1 The 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 associated id value 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.

Example 16. Configure elements.

<message 
        from='kingclaudius@shakespeare.lit/castle'
        to='laertes@shakespeare.lit/castle'>
        <wb xmlns='http://jabber.org/protocol/svgwb'
            session='851ba2'
            hash='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>
                </configure>
        </wb>
</message>

4.6.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.6.3 The 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 'from' and 'to' 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 "m" are replaced by the the content of the <attribute/> element.

4.6.4 The content element

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.6.5 The 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 is inserted to its new position according to it's index value according to the same rule as with inserting new elements.

5. Business Rules

OPTIONAL.

6. Implementation Notes

It's strongly recommended that for operations such as translations of position or rotations, clients make use of the 'transform' attribute of the SVG elements. Especially for elements with many coordinate points (e.g. long <path/> elements) it would be both wasteful and cumbersome to recalculate and send the new coordinates instead of sending a transformation matrix.

7. Security Considerations

All elements specified by this JEP are contained in a <message/> stanza and are analogous to the <body/> element in their security considerations.

8. IANA Considerations

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

9. Jabber Registrar Considerations

9.1 Protocol Namespaces

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

9.2 Service Discovery Identities

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

10. XML Schema


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

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

        <xs:element name='wb'>
                <xs:complexType>
                        <xs:sequence>
                                <xs:element name='protocol' minOccurs='0'>
                                        <xs:complexType>
                                                <xs:sequence>
                                                        <xs:element name='abort-negotiation' minOccurs='0'>
                                                                <xs:complexType>
                                                                        <xs:sequence>
                                                                                <xs:element name='supported-features' minOccurs='0'>
                                                                                        <xs:complexType>
                                                                                                <xs:sequence>
                                                                                                        <xs:element name='feature' minOccurs='0'/>
                                                                                                </xs:sequence>
                                                                                        </xs:complexType>
                                                                                </xs:element>
                                                                                <xs:element name='peer-already-in-session' minOccurs='0'/>
                                                                        </xs:sequence>
                                                                </xs:complexType>
                                                        </xs:element>
                                                        <xs:element name='invitation' minOccurs='0'>
                                                                <xs:complexType>
                                                                        <xs:sequence>
                                                                                <xs:element name='feature' minOccurs='0'/>
                                                                        </xs:sequence>
                                                                </xs:complexType>
                                                        </xs:element>
                                                        <xs:element name='connect-request' minOccurs='0'/>
                                                        <xs:element name='accept-invitation' minOccurs='0'/>
                                                        <xs:element name='history-offer' minOccurs='0'>
                                                                <xs:complexType>
                                                                        <xs:sequence>
                                                                                <xs:element name='feature' minOccurs='0'/>
                                                                        </xs:sequence>
                                                                </xs:complexType>
                                                        </xs:element>
                                                        <xs:element name='accept-history' minOccurs='0'/>
                                                        <xs:element name='document-begin' minOccurs='0'/>
                                                        <xs:element name='document-end' minOccurs='0'>
                                                                <xs:complexType>
                                                                        <xs:sequence>
                                                                                <xs:element name='document-end'>
                                                                                        <xs:complexType>
                                                                                                <xs:attribute name='sender'
                                                                                                        type='xs:string'
                                                                                                        use='required'/>
                                                                                                <xs:attribute name='hash'
                                                                                                        type='xs:string'
                                                                                                        use='required'/>
                                                                                        </xs:complexType>
                                                                                </xs:element>
                                                                        </xs:sequence>
                                                                </xs:complexType>
                                                        </xs:element>
                                                </xs:sequence>
                                        </xs:complexType>
                                </xs:element>
                                <xs:element name='new' minOccurs='0'>
                                        <xs:complexType>
                                                <xs:attribute name='id'
                                                        type='xs:string'
                                                        use='required' />
                                                <xs:attribute name='index'
                                                        type='xs:float'
                                                        use='required' />
                                                <xs:attribute name='version'
                                                        type='xs:nonNegativeInteger'
                                                        use='optional' />
                                        </xs:complexType>
                                        <xs:annotation>
                                                <xs:documentation>
                                                        One element of the SVG Tiny profile here. How?
                                                </xs:documentation>
                                        </xs:annotation>
                                </xs:element>
                                <xs:element name='configure' minOccurs='0'>
                                        <xs:complexType>
                                                <xs:attribute name='target'
                                                        type='xs:string'
                                                        use='required'/>
                                                <xs:attribute name='version'
                                                        type='xs:integer'
                                                        use='required' />
                                                <xs:sequence>
                                                        <xs:element name='attribute' minOccurs='0'>
                                                                <xs:complexType>
                                                                        <xs:attribute name='name'
                                                                                type='xs:string'
                                                                                use='required'/>
                                                                </xs:complexType>
                                                        </xs:element>
                                                        <xs:element name='parent' minOccurs='0'/>
                                                        <xs:element name='content' minOccurs='0'/>
                                                </xs:sequence>
                                        </xs:complexType>
                                </xs:element>
                                <xs:element name='move' minOccurs='0'>
                                        <xs:complexType>
                                                <xs:attribute name='target'
                                                        type='xs:string'
                                                        use='required'/>
                                                <xs:attribute name='di'
                                                        type='xs:float'
                                                        use='required' />
                                        </xs:complexType>
                                </xs:element>
                                <xs:element name='remove' minOccurs='0'>
                                        <xs:complexType>
                                                <xs:attribute name='target'
                                                        type='xs:string'
                                                        use='required'/>
                                        </xs:complexType>
                                </xs:element>
                        </xs:sequence>
                </xs:complexType>
        </xs:element>
</xs:schema>

        

11. 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 JEP.

Dale Harvey also provided valuable input especially regarding the session negotiation process.


Notes


Revision History

Version 0.0.1 (2006-06-19)

Initial version.

(jg)


END