XEP-xxxx: Whiteboard

A protocol describing how to whiteboard over XMPP.


WARNING: This document has not yet been accepted for consideration or approved in any official manner by the XMPP Standards 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@xmpp.org> mailing list.


Document Information

Series: XEP
Number: xxxx
Publisher: XMPP Standards Foundation
Status: ProtoXEP
Type: Standards Track
Version: 0.7.1
Last Updated: 2001-07-17
Approving Body: XMPP Council
Dependencies: XMPP Core, XEP-0001, XEP-0045, XEP-0096
Supersedes: None
Superseded By: None
Short Name: NOT YET ASSIGNED

Author Information

Michael Bishop

Email: michael.bishop@dataline.com

Keith Lirette

Email: keith.lirette@gd-ais.com

Boyd Fletcher

Email: boyd@cox.net

Legal Notice

This XMPP Extension Protocol is copyright 1999 - 2007 by the XMPP Standards Foundation (XSF) and is in full conformance with the XSF's Intellectual Property Rights Policy (<http://www.xmpp.org/extensions/ipr-policy.shtml>). This material may be distributed only subject to the terms and conditions set forth in the Creative Commons Attribution License (< http://creativecommons.org/licenses/by/2.5/ >).

Discussion Venue

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

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 XMPP Standards 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. Session Management
    4.1. Free-For-All Session
    4.2. Moderated Session
    4.3. Round Robin Session
5. User Roles
    5.1. Visitor Role
    5.2. Participant Role
    5.3. Presenter Role
    5.4. Moderator Role
    5.5. Administrator Role
    5.6. WB Roles to MUC Roles Mapping
6. Whiteboard Management
    6.1. Create Whiteboard
       6.1.1. Create Whiteboard - Error Codes
7. Page Management
    7.1. Create Page
       7.1.1. Create Page - Error Codes
    7.2. Reorder Page
       7.2.1. Reorder Page - Error Codes
    7.3. Switch Page
       7.3.1. Switch Page - Error Codes
    7.4. Delete Page
       7.4.1. Delete Page - Error Codes
8. Page Entities
    8.1. Create Element
       8.1.1. Create Element - Error Codes
    8.2. Update Element
       8.2.1. Update Element - Error Codes
    8.3. Reorder Element
       8.3.1. Reorder Element - Error Codes
    8.4. Delete Element
       8.4.1. Delete Element - Error Codes
9. Element Text
    9.1. Additional Name Spaces
       9.1.1. XLINK
       9.1.2. SVGX
       9.1.3. Classification
       9.1.4. Other Name Spaces
10. Layers
11. History
12. Business Rules
    12.1. afterId
    12.2. parentId
    12.3. pageId
13. Security Considerations
14. IANA Considerations
15. XMPP Registrar Considerations
16. XML Schema
Notes
Revision History


1. Introduction

Describe a whiteboarding protocol over XMPP. The protocol covers sessions for both one-to-one whiteboarding and group whiteboarding.

2. Requirements

The whiteboard (WB) protocol must support the following modes of operation:

The WB must also be able to support the following capabilities:

3. Glossary

Table 1: Whiteboard Terms

Action Any single command sent via XMPP in a WB.
Append When an element is appended to a parent element, it becomes the last child of that element. For example, appending a rendered element to a layer results in the rendered element being the last child of that layer.
Element Any single XML tag. Layers are elements that contain rendered elements. In general, one create action on a WB results in the creation of a single element. An element can contain other elements: <g>...</g> or be self-contained: <rect/>.
Layer A special instance of the SVG <g> element. Layers are tagged with additional information from the SVGX name space.
Page A single SVG XML document. Other name spaces may be linked in. A whiteboard is a collection of these documents.
UUID Universally unique identifier.
Whiteboard This is the document to which elements, layers, and pages are appended. Represented in the file system as the WBF format.

4. Session Management

This section describes how users can start/join/leave/end a whiteboard. Participation in a whiteboard denotes a whiteboard session. Permissions are determined in one of two ways. If the whiteboard is taking place in a MUC, the participant's role is determined by their MUC role. In a one-to-one chat, the initiator of the WB provides the role for the recipient. The sessions described below are suggested scenarios for whiteboarding.

4.1 Free-For-All Session

A free-for-all session is most commonly implemented when a one-to- one session is initiated with another user and the initiator does not specify a role for the recipient. There are no roles or permissions in a free-for-all session. Every user can perform every function on the WB. A free-for-all session is best implemented for ad-hoc situation where minimal configuration is desired.

4.2 Moderated Session

A moderated session is a collaborative yet controlled session. One or more users are designated as moderators. They can allow and disallow other users the right to manipulate the WB. In a typical moderated session, a user will request permission to manipulate the WB. The moderator will grant the request and the user will contribute to the WB. When that user is done, his rights are revoked and issued to the next requester. This session is ideal for collaborative meetings. A moderator can invite any number of participants and allow them to provide feedback and ideas in an orderly and regulated manner.

4.3 Round Robin Session

This is similar to a moderated session. The user who begins the WBS has full control of the WB. What this user can do is “pass the baton”; relinquish their control in order to pass it on to another user. At any given time, one user is in control of the WB and the other users are visitors. This mode is ideal for presentations where each presenter controls the WB for their part of the session. Control does not need to be passed on; the initiator of the WBS may be the only presenter and everyone else invited to the session remains as a visitor for the entire duration. Any moderator can grab the baton and/or give the baton to another user. If two or more moderators grab the baton at the (nearly) same time, the last one will get it.

5. User Roles

In any given WB, a user usually has a role associated. A user without a role must not be in a WB that requires them. If a WB does not require roles, then all users have all permissions. Moderated and Round Robin sessions require roles.

5.1 Visitor Role

This is the role with the least permissions. A user in a visitor role may only observe a WB. They cannot perform any WB-related functions except for joining and leaving.

5.2 Participant Role

This role is a hybrid between the presenter role and the visitor role. A participant is a visitor until he/she requests (and is granted) permission to manipulate the WB or he/she is passed control in a round robin session.

5.3 Presenter Role

This role allows a user to manipulate the WB. They can create/ update/delete elements and pages. They can also enforce page switching. Presenters have no control over user permissions.

5.4 Moderator Role

A moderator inherits all the functionality given to a presenter. In addition, a moderators may grant/revoke/change a user's role and invite/remove users from a WB. A moderator can also create/destroy a WB.

5.5 Administrator Role

An administrator has full control over the server functionality. In addition to the permissions granted to a moderator, an administrator allow/disallow any WB activity on a server or a room. This role is out of the scope of the WB protocol and will not be discussed further.

5.6 WB Roles to MUC Roles Mapping

The WB, when associated with a MUC room, leverages the roles and affiliations of that room. The following table maps the above conceptual roles to actual MUC roles.

Table 2: Role Mappings

MUC Role WB Role
Visitor Visitor
Participant Participant
Participant with voice Presenter
Moderator Moderator

MUC was chosen as the basis for WB permissions in order to simplify the configuration of WB permissions for both users and software developers and because if offers all of the functionality required. If a separate permissioning system for WB was chosen then users would have to learn how to manipulate them and software developers would have to implement a separate system.

6. Whiteboard Management

This section describes how users can create/destroy a whiteboard.

6.1 Create Whiteboard

This command is issued when a user wishes to create a new WB. Since only one WB can exist at a time, this command will replace the current WB. A user must have permission to issue this command, otherwise an error will be returned.

            
            <message xmlns="jabber:client" id="8Jg7O-48"
                     to="test.user@jabber.org/Transverse0.9b Alexandretta"
                     xml:lang="en" type="chat">	
                <action type="create_whiteboard"
              	        id="SVGWB-8CFAB632-5D19-DDAE-9536-CEA6FEF3503E"
              	        whiteboardId="SVGWB-8CFAB632-5D19-DDAE-9536-CEA6FEF3503E"
                        role=”visitor”
                        version=”1.0”
                        seqNum="1"/>
            </message>
        

Table 3: Create Whiteboard Attributes

id The ID of the first page of the WB. A WB cannot have zero pages so when a create whiteboard is issued, the ID of the first page is supplied. This field is required.
whiteboardId The ID of the WB. This field is required.
role The role of the invitee. This field is not required. It is only used in a one-to-one session if the initiator wishes to assign a role to the recipient/invitee.
version The version of the WB protocol being used. This field is required to ensure compatibility.
seqNum The starting sequence number for this whiteboard. See the section on history for usage of the sequence number. This field is required if this implementation supports history.

When this command is issued, the client must create a new WB with a single page. This single page must have the value of the id attribute assigned to it.

6.1.1 Create Whiteboard - Error Codes

Table 4: Error Codes

401 Returned if the user's role does not allow them to create a new whiteboard.
500 Returned if the server fails in processing the action.
501 Returned if the server does not support the requested WB protocol version.

7. Page Management

This section describes how to create/reorder/delete pages on a WB.

7.1 Create Page

This command is issued when a user wishes to add a new page to the WB.

            
           <message xmlns="jabber:client" id="8Jg7O-50"
                    to="test.user@jabber.org/Transverse0.9b Alexandretta"
                    xml:lang="en" type="chat">
               <action type="create_page" seqNum="8">
                   <page id="SVGWB-BEBCC71F-0A1F-BC61-AC01-9F7DE06540AB" 				            afterId="SVGWB-9985A39B-475C-C327-5C15-00C651AD89D8"
                         name="page2"/>
               </action>
           </message>
           
       

Table 5: Create Page Attributes

id The ID assigned to the new page. This field must be assigned.
afterId The ID assigned to the page that the new page will come after. If this optional field is not assigned, the new page will become the first page in the WB.
name The name/title assigned to the new page. This is an optional field for use with clients that show a list of pages by name.

7.1.1 Create Page - Error Codes

Table 6: Error Codes

401 Returned if the user's role does not allow them to create a page.
406 Returned if the request is invalid.
500 Returned if the server fails to process the action.

7.2 Reorder Page

This command is issued when a user wishes to change the ordering of pages in a WB.

            
            <message xmlns="jabber:client" id="8Jg7O-90"
                     to="test.user@jabber.org/Transverse0.9b Alexandretta"
                     xml:lang="en" type="chat">	
                <action type="reorder_page" seqNum="2">
                    <page id="SVGWB-F38E6DDE-197B-E530-E63C-D12251EF8E7B"
                          afterId=”SVGWB-8E7B6DDE-E530-197B-E63C-D12251EFF38E”/>
                </action>
            </message>
           
       

Table 7: Reorder Page Attributes

id The ID of the page to reorder. This field is required.
afterId The ID of the page that the given page will be moved after. If this field is not supplied, it is assumed the given page becomes the first page. This field is optional.

7.2.1 Reorder Page - Error Codes

Table 8: Error Codes

401 Returned if the user's role does not allow them to reorder pages.
406 Returned if the request is invalid. For example, an invalid page ID is supplied.
500 Returned if the server fails to process the action.

7.3 Switch Page

This command is issued when a user wishes to switch the active page in a WB session. This command should be ignored by the client if the page with the given ID cannot be found.

            
            <message xmlns="jabber:client" id="8Jg7O-51"
                     to="test.user@jabber.org/Transverse0.9b Alexandretta"
                     xml:lang="en" type="chat">	
                <action type="switch_page" seqNum="6">
                    <page id="SVGWB-F38E6DDE-197B-E530-E63C-D12251EF8E7B"/>
                </action>
            </message>
           
       

Table 9: Switch Page Attributes

id The ID of the page to switch to. This field is required.

7.3.1 Switch Page - Error Codes

Table 10: Error Codes

401 Returned if the user's role does not allow them to switch pages.
406 Returned if the request is invalid. For example, an invalid page ID is supplied.
500 Returned if the server fails to process the action.

7.4 Delete Page

This command is issued when a user wishes to remove a page from the WB. If only one page remains in the WB, deleting it must not be allowed. A client should not delete the current page. The current page is the page that a presenter is viewing. For example, a presenter is on page one and switches to page two. A visitor is on page one and has page locking turned on. The visitor remains on page one, but the current page is page two. To delete the current page, a client should first switch to another page.

            
            <message xmlns="jabber:client" id="8Jg7O-52"
                     to="test.user@jabber.org/Transverse0.9b Alexandretta"
                     xml:lang="en" type="chat">
                <action type="delete_page" seqNum="9">
                    <page id="SVGWB-9985A39B-475C-C327-5C15-00C651AD89D8"/>
                </action>
            </message>
           
       

Table 11: Delete Page Attributes

id The ID of the page to be deleted. This field is required.

7.4.1 Delete Page - Error Codes

Table 12: Error Codes

401 Returned if the user's role does not allow them to delete pages.
406 Returned if the request is invalid. For example, an invalid page ID is supplied.
500 Returned if the server fails to process the action.

8. Page Entities

This section describes how to interact with a single page. On a page, elements can be created, updated, moved, reordered, switched to, and deleted.

8.1 Create Element

This command is issued when a user wishes to add a new element belonging to the current page.

        
        <message xmlns="jabber:client" id="8Jg7O-53"
                 to="test.user@jabber.org/Transverse0.9b Alexandretta"
                 xml:lang="en" type="chat">	
            <action type="create_element" seqNum="10">
                <elementText pageId="SVGWB-CADEDC0C-7E1E-14E1-E0F3-2323E15855AE"          
                             id="SVGWB-838873D7-989B-A085-4D99-17356529DA3E"
                             parentId="SVGWB-B5E9CFA7-D303-73C3-A504
                                       -111C5EE74377">
                    <rect fill-opacity="1" stroke="black"
                          id="SVGWB-838873D7-989B-A085-4D99-17356529DA3E"     
                          transform="matrix(0.827943046226628, 0.0, 0.0,    
                                            0.827943046226628, 0.0, 
                                            -10.452774047851562)"
                          width="199" stroke-opacity="1" fill="gray"    
                          xmlns:xlink="http://www.w3.org/1999/xlink"
                          stroke-width="1" height="196"
                          pointer-events="visible" 
                          xmlns:svgx="http://jabber.org/svgx"
                          xmlns="http://www.w3.org/2000/svg"
                          x="142" y="274"/>
                </elementText>
            </action>
        </message>
       
       

Table 13: Create Element Attributes

pageId The ID of the page to which the new element belongs. This field must be populated.
id The ID of the new element. This field must be populated.
parentId The ID of the element of which the new element is a child of. This field should be populated. If it is not, the root (SVG) element of the page is assumed as the parent.
afterId The ID of the element the new element comes after. This is an optional field. If it is not assigned, it is appended to the element defined in the parentId field.
<elementText> The elementText tag encloses a miniature SVG document that represents the new element. This field must contain valid SVG. Name spaces are included to maintain the validity of the document. Multiple elementText tags may be contained in a single create element event.

8.1.1 Create Element - Error Codes

Table 14: Error Codes

401 Returned if the user's role does not allow them to create an element.
406 Returned if the request is invalid. For example, invalid SVG is supplied.
500 Returned if the server fails to process the action.
501 Returned if multiple elementText elements are not supported in the given implementation.

8.2 Update Element

This command is issued when a user changes attributes of an existing element on the page. This command is very similar to a create element. When a client receives an update element, they must create the element if it doesn't exist. If it does exist, they must update the attributes of the element. The entire element is included in the command.

        
        <message xmlns="jabber:client" id="8Jg7O-54"
                 to="test.user@jabber.org/Transverse0.9b Alexandretta"
                 xml:lang="en" type="chat">		
            <action type="update_element" seqNum="2">
                ...see create element.
            </action>
        </message>
       
       

8.2.1 Update Element - Error Codes

See Create Element - Error Codes.

8.3 Reorder Element

This command is issued when an element is reordered within a page. This command is typically issued when users want to move elements to the front or push them to the back of a page. This command is only issued to change the Z-order of an element. To change the X/Y coordinates of an element (i.e. drag and drop), an update to the transform attribute of the element is applied. This command is for changing the stacking order of elements by reordering the element's position in the XML document (page).

        
        <message xmlns="jabber:client" id="8Jg7O-55"
                 to="test.user@jabber.org/Transverse0.9b Alexandretta"
                 xml:lang="en" type="chat">	      
            <action type="move_element" seqNum="4">
                <elementText id="SVGWB-838873D7-989B-A085-4D99-17356529DA3E"
                             parentId="SVGWB-B5E9CFA7-D303-73C3-A504
                                       -111C5EE74377"
                             afterId="SVGWB-7F4D6592-D750-33ED-12F3
                                      -8B9A47E5135C"
                             pageId="SVGWB-CADEDC0C-7E1E-14E1-E0F3
                                     -2323E15855AE"/>
            </action>
        </message>
        
        

The priority for the attributes is standard. If an afterId is supplied, the element is moved after the element with the given afterId. If a parentId is supplied, the element is moved as the first child of the element with the given parentId. If neither is supplied, the element is moved as the first child of the root (SVG) element of the page.

Table 15: Reorder Element Attributes

id The ID of the element to be reordered. This field must be supplied.
parentId The ID of the element to be the new parent of the reordered element. This field should be supplied. If it is not, the element is reordered as the first child of the root SVG element.
afterId The ID of the element to precede the reordered element. This field may be supplied. If it is not supplied, the element is reordered as the first child of the element represented by the parentId.
pageId The ID of the page containing the reordered element. This field should be supplied.

8.3.1 Reorder Element - Error Codes

Table 16: Error Codes

401 Returned if the user's role does not allow them to reorder an element.
406 Returned if the request is invalid. For example, an invalid ID is supplied.
500 Returned if the server fails to process the action.

8.4 Delete Element

This command is issued when an element is removed from the WB. If the element cannot be found, no action should be taken. The remote server/client may report an error.

        
        <message xmlns="jabber:client" id="8Jg7O-56"
                 to="test.user@jabber.org/Transverse0.9b Alexandretta"
                 xml:lang="en" type="chat">	      
            <action type="delete_element" seqNum="2">
                <elementText id="SVGWB-416E41E9-2A91-CCF7-01A0-5E6D9ABFC259"
                             pageId="SVGWB-7F82F09D-253E-52B3-3526
                                     -E6788EF5FF83"/>
            </action>
        </message>
        
        

Table 17: Delete Element Attributes

id The ID of the element to be deleted. This field must be supplied.
pageId The ID of the page containing the deleted element. This field should be supplied. If it is not, the current page in the session is assumed.

8.4.1 Delete Element - Error Codes

Table 18: Error Codes

401 Returned if the user's role does not allow them to delete an element.
406 Returned if the request is invalid. For example, an invalid ID is supplied.
500 Returned if the server fails to process the action.

9. Element Text

This section is about the <elementText> included with element updates and how they should be handled. An <elementText> element must contain a valid document. In order for an XML parser to interpret the XML, all name spaces used in the given element must be provided. A remote client is not required to process XML from any name space except the SVG name space. Other name spaces can be considered optional extended information.

    
    <elementText>
        <g style="display: block"
           xmlns="http://www.w3.org/2000/svg"
           xmlns:svgx="http://jabber.org/svgx"
           id="SVGWB-F838C04B-4EA7-CF37-37A0-8D9067527253"
           pointer-events="none"
           svgx:name="layer1"
           svgx:type="layer"/>
    </elementText>
    
    

The above example describes a <g> or grouping element. The style, id, and pointer-events attributes belong to the SVG name space and must be processed by the remote client. This can be determined because the SVG name space is declared without a prefix. (xmlns="http://www.w3.org/2000/svg") The svgx:name and svgx:type are extended attributes and may be processed by the remote client. In this case, the svgx:type describes that the grouping element is being used as a layer. The svgx:name describes the name of this layer (layer1). Appropriately, the SVGX name space is also declared. The rendering of the SVG content in the document must not be affected by additional name spaces.

9.1 Additional Name Spaces

At the time of writing, only two additional name spaces have been identified for this protocol:

9.1.1 XLINK

This name space is used in the SVG standard. It's primary use is to link in additional resources from other files. XLINK is commonly seen in <image> elements to link to and display the image in an SVG document.

9.1.2 SVGX

This name space is used for extended SVG attributes. Currently, only two attributes exist in this name space. Type is used to describe extra information about how a particular SVG element is being used. The <g> tag in SVG is simply a grouping tag used for many purposes. The svgx:type attribute defined in the example shown in 5.0 describes the <g> tag as a layer. This differentiates it from other <g> tags in a document that may not be a layer. A client that wishes to describe layers may use this information. Name is used to tag a given element with a name. In the example shown in the elementText section, a client that wishes to display a list of layers may also display each layer's name that's given in the svgx:name attribute.

9.1.3 Classification

A future possibility for extra information may be classification labels. These labels would describe a WB, page, layer, or individual element with a DDMS compliant classification label. The DDMS schema would probably be linked into the document to adhere to these specifications.

9.1.4 Other Name Spaces

Other name spaces may be linked in as well. Elements that use extended name spaces must send the name space with every element that uses it. (See section 5.0's reference to all <elementText> elements must contain valid documents.) The extended name spaces must not interfere with the visual rendering of the SVG content.

10. Layers

One concept unique to the WB protocol that is not officially part of the SVG specification is the concept of layers. Layers are not directly supported by the SVG standard, so it's important that the protocol defines a single way to identify them. Layers must be identified with a <g> tag containing an SVGX attribute type set to the value of “layer”:

    
    <g style="display: block"
       xmlns="http://www.w3.org/2000/svg"
       xmlns:svgx="http://jabber.org/svgx"
       id="SVGWB-F838C04B-4EA7-CF37-37A0-8D9067527253"
       pointer-events="none"
       svgx:name="layer1"
       svgx:type="layer"/>
    
    

All rendered elements on a document should be drawn on a layer. Optionally, a layer also can be named with the SVGX attribute name. It is worth noting again, that if a client does not understand the concept of layers, the rendered content will still be correct. Layers are optional content and must not affect the appearance of the document.

11. History

History is used when a WB client is disconnected from the WB and needs to regain the current state. The first sequence number in a whiteboard is supplied with the create whiteboard command. Every subsequent whiteboard action will contain an incremental number. A client can request every change that has happened since a particular sequence number. Sequence numbers are assigned to every WB action. A WB server holds a finite amount of actions. If the sequence number being requested is no longer available, the client receives the entire WB instead, starting with the create whiteboard command.

12. Business Rules

This section describes the order in which WB events should be processed and the default values that should be assumed if certain information is not provided.

12.1 afterId

If an afterId is provided with a WB event, it should be used. The element being manipulated must come after the element carrying the afterId.

12.2 parentId

If no afterId is provided, the parentId must be the next guideline to adhere to. The element being manipulated must be the first child of the element with the given parentId.

12.3 pageId

The event recipient must always look for a pageId. It describes the ID of the page to which the event belongs. If no pageId is specified, the current page of the WB must be assumed. The pageId can be found in the root element of an SVG document.

13. Security Considerations

Because the SVG spec support client-side JavaScript code, clients should exercise care in who they begin a whiteboard session with. SVG snippets should also be checked for validity and should also adhere to an arbitrary size to avoid elements of unreasonable length.

14. IANA Considerations

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

15. XMPP Registrar Considerations

Possible requirement to register the name spaces involved with this protocol? Action and SVGX name spaces come to mind.

16. XML Schema

        
        <?xml version="1.0" encoding="UTF-8"?>

            <!--
                Document   : action.xsd
                Created on : March 2, 2006, 12:27 PM
                Author     : Michael W. Bishop
                Description:
                    Describe XMPP messages passed back and forth in a
                    whiteboarding session.



                Copyright (C) 2006-2007 by Dataline, Inc.  
                All Rights Reserved.

                DEVELOPER POC
                Michael W. Bishop
                michael.bishop@dataline.com
                
                Keith Lirette
                keith.lirette@gd-ais.com

                Boyd Fletcher
                boyd@cox.net
            -->

            <xs:schema elementFormDefault="qualified"
                        targetNamespace="http://jabber.org/action"
                        xmlns:ac="http://jabber.org/action"
                        xmlns:xs="http://www.w3.org/2001/XMLSchema">

                <!-- Describes the "type" attribute of the "action" element.
                     The "type" element should only be one of the described
                     values.

                     Example: <action type="create_element"></action>
                -->
                <xs:simpleType name="actionType">
                    <xs:restriction base="xs:string">
                        <xs:enumeration value="create_element"/>
                        <xs:enumeration value="create_page"/>
                        <xs:enumeration value="create_whiteboard"/>
                        <xs:enumeration value="delete_element"/>
                        <xs:enumeration value="delete_page"/>
                        <xs:enumeration value="load_whiteboard"/>
                        <xs:enumeration value="move_element"/>
                        <xs:enumeration value="query"/>
                        <xs:enumeration value="switch_page"/>
                        <xs:enumeration value="update_element"/>
                    </xs:restriction>
                </xs:simpleType>

                <xs:complexType name="elementTextType">
                    <xs:sequence minOccurs="1" maxOccurs="1">
                        <xs:any />
                    </xs:sequence>
                    <xs:attribute name="afterId" type="xs:string"/>
                    <xs:attribute name="file" type="xs:string"/>
                    <xs:attribute name="id" type="xs:string"/>
                    <xs:attribute name="lang" type="xs:string"/>
                    <xs:attribute name="pageId" type="xs:string"/>
                    <xs:attribute name="parentId" type="xs:string"/>
                    <xs:attribute name="type" type="xs:string"/>
                </xs:complexType>

                <!-- Similar to the "elementTextType" except it describes the ID
                     of an entire document.  (ID of the root "SVG" element).
                -->
                <xs:complexType name="pageType">
                    <xs:attribute name="id" type="xs:string"/>
                    <xs:attribute name="afterId" type="xs:string"/>
                    <xs:attribute name="name" type="xs:string"/>
                </xs:complexType>

                <!-- Describes the main "action" element which has the "type"
                     attribute, any number of sub-elements "element" of
                     "elementTextType" or any number of sub-elements "page" of
                     "pageType".  There must be at least one of either "element"
                     or "page".  -->
                <xs:element name="action">
                    <xs:complexType>
                        <xs:sequence>
                            <xs:element name="page"
                                        type="ac:pageType"
                                        minOccurs="0"
                                        maxOccurs="unbounded"/>
                            <xs:element name="elementText"
                                        type="ac:elementTextType"
                                        minOccurs="0"
                                        maxOccurs="unbounded"/>
                        </xs:sequence>
                        <xs:attribute name="type" type="ac:actionType"
                                      use="required"/>
                        <xs:attribute name="id" type="xs:string"/>
                        <xs:attribute name="jid" type="xs:string"/>
                        <xs:attribute name="seqNum" type="xs:string"/>
                        <xs:attribute name="sessionID" type="xs:string"/>
                        <xs:attribute name="whiteboardId" type="xs:string"/>
                    </xs:complexType>
                </xs:element>
            </xs:schema>
        
    


Notes


Revision History

Version 0.7.1 (2001-07-17)

First draft.

(mwb)

END