JEP-xxxx: An SVG Based Whiteboard Format

This JEP defines the format of the XML file representing 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 root whiteboard element
4.3. The metadata element
4.4. Pages
4.5. Layers
4.6. Other Metadata
5. Implementation Notes
6. Security Considerations
7. IANA Considerations
8. Jabber Registrar Considerations
8.1. Protocol Namespaces
8.2. Service Discovery Identities
9. XML Schema
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".

amp;jep0113; 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:

This JEP defines the format of the XML file that represents a whiteboard. The format relies heavily on SVG 1.1 but it was seen necessary to add some features into the format; namely formally defined pages and layers. This JEP doesn't specify how the common whiteboard document is to be modified, it is suggested you leverage &jepxxxx; (SXdE) for that.

2. Requirements

  1. The document format must allow sharing of freehand drawing on a common whiteboard.
  2. The document format must support multiple pages.
  3. The document format must allow including images in common formats.
  4. The document format must allow including foreign object that each client MAY interpret.
  5. The document format must rely on existing vector graphics standard in order to be simple to render.

3. Glossary

4. Use Cases

4.1 Querying Whiteboard Abilities

Before attempting to share a whiteboard document, 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 document format, it MUST return a feature of "http://jabber.org/protocol/whiteboard":

Example 2. Service discovery response

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

4.2 The root whiteboard element

The root element of the document is <whiteboard/> and MUST posess the attributes 'xmlns' and 'xmlns:wb' with values "http://jabber.org/protocol/whiteboard" and "http://jabber.org/protocol/whiteboard#metadata" respectively.

The root element MUST only contain <metadata/> and <svg/> elements.

Example 3. The root whiteboard element and its allowed children

<whiteboard xmlns='http://jabber.org/protocol/whiteboard'
	    xmlns:wb='http://jabber.org/protocol/whiteboard#metadata'>
	<metadata .../>
	<metadata .../>
	<metadata .../>
	<svg .../>
		...
	</svg>
	<svg .../>
	...
	</svg>
	<svg .../>
	...
	</svg>
</whiteboard>

4.3 The metadata element

Each <metadata/> element MUST posess the attribute 'variable' and contain the intended metadata. Clients SHOULD be able to show the user some kind of (table) structure representing the metadata included in these elements.

Example 4. Some example metadata elements

<whiteboard xmlns='http://jabber.org/protocol/whiteboard'
	    xmlns:wb='http://jabber.org/protocol/whiteboard#metadata'>
	<metadata name='title'>Mona Lisa</metadata>
	<metadata name='description'>A copy of Mona Lisa drawn with mouse.</metadata>
	<metadata name='classification'>Public</metadata>
</whiteboard>

4.4 Pages

Each <svg/> element represents a page in the whiteboard. It MUST contain the attribute 'wb:type' with the value "page". An <svg/> element MUST be standalone SVG 1.1 Tiny document in the sense that it MUST NOT refer to anything, except the 'wb' prefix, defined in the root <whiteboard/> element. Each <svg/> element SHOULD also contain the attributes 'width' and 'height' in order to specify the dimensions of the page.

Example 5. Some example whiteboard pages

<whiteboard xmlns='http://jabber.org/protocol/whiteboard'
	    xmlns:wb='http://jabber.org/protocol/whiteboard#metadata'>
	<metadata name='title'>Mona Lisa</metadata>
	<metadata name='description'>A copy of Mona Lisa drawn with mouse.</metadata>
	<metadata name='classification'>Public</metadata>
	<svg wb:type='page' xmlns='http://www.w3.org/2000/svg' version='1.1' baseProfile='tiny' width='600' height='600'>
		<circle cx='45'
			cy='24'
			r='10'/>
	</svg>
	<svg wb:type='page' xmlns='http://www.w3.org/2000/svg' version='1.1' baseProfile='tiny' width='600' height='600'>
		<path d='M10 10L30 50L50 10Z'/>
	</svg>
</whiteboard>

4.5 Layers

An SVG <g/> element MAY be given an additional attribute 'wb:type' with value "layer" in order to formally recognize it as a layer. The rendering of such an element is identical to a regular <g/> element but a client MAY choose to provide special controls for modifying layers in a different way than regular groups of objects (e.g. enabling and disabling rendering them).

Example 6. Some example whiteboard layers

<whiteboard xmlns='http://jabber.org/protocol/whiteboard'
	    xmlns:wb='http://jabber.org/protocol/whiteboard#metadata'>
	<metadata name='title'>Mona Lisa</metadata>
	<metadata name='description'>A copy of Mona Lisa drawn with mouse.</metadata>
	<metadata name='classification'>Public</metadata>
	<svg wb:type='page' xmlns='http://www.w3.org/2000/svg' version='1.1' baseProfile='tiny' width='600' height='600'>
		<g wb:type='layer'>
			<circle cx='45'
				cy='24'
				r='10'/>
		</g>
	</svg>
	<svg wb:type='page' xmlns='http://www.w3.org/2000/svg' version='1.1' baseProfile='tiny' width='600' height='600'>
		<g wb:type='layer'>
			<path d='M10 10L30 50L50 10Z'/>
		</g>
	</svg>
</whiteboard>

4.6 Other Metadata

Each element in the document MAY also contain a 'wb:name' attribute that can contain a descriptive name for the element which MAY be used for for example showing an index of items on the whiteboard to the user.

Example 7. Some example whiteboard elements with names

<whiteboard xmlns='http://jabber.org/protocol/whiteboard'
	    xmlns:wb='http://jabber.org/protocol/whiteboard#metadata'>
	<metadata name='title'>Mona Lisa</metadata>
	<metadata name='description'>A copy of Mona Lisa drawn with mouse.</metadata>
	<metadata name='classification'>Public</metadata>
	<svg wb:type='page' wb:name='Page with a circle' xmlns='http://www.w3.org/2000/svg' version='1.1' baseProfile='tiny' width='600' height='600'>
		<g wb:type='layer' wb:name='Layer with a circle'>
			<circle cx='45'
				cy='24'
				r='10'/>
		</g>
	</svg>
	<svg wb:type='page' xmlns='http://www.w3.org/2000/svg' version='1.1' baseProfile='tiny' width='600' height='600'>
		<g wb:type='layer' wb:name='Layer with a path'>
			<path  wb:name='Path' d='M10 10L30 50L50 10Z'/>
		</g>
	</svg>
</whiteboard>

5. 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. This is a considerably lighter weight approach that specifiying new coordinate points especially for elements like long paths.

6. Security Considerations

This document format specification involves no security considerations. They are related to transfering and storing instances of such document.

7. IANA Considerations

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

8. Jabber Registrar Considerations

8.1 Protocol Namespaces

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

8.2 Service Discovery Identities

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

9. XML Schema 


TODO

Notes

Revision History

Version 0.0.1 (2006-06-19)

Initial version.

(jg)

END