MEMO: SVG & XMPP
                          ----------------

                       Mats Bengtsson (040709)


INTRODUCTION
------------

SVG is used for static documents and it is not straightforward to apply it
to a streaming environment as XMPP. SVG is a display language for 2D graphics
and not a communication language. Streaming in SVG usually means that a static
document is downloaded over a network, and display can start before the 
document has been completely downloaded. Streaming in XMPP means something very
different.

SVG documents or elements are included as subelements of XMPP message elements.
There are three message types, normal, chat, and groupchat, and each
must be treated separately. Normal messages posseses no special consideration.
For chat and groupchat messages, however, there are two particular problems:
synchronization and editing. For groupchats an additional complication is
that the room must keep the entire state of the whiteboard.

An additional issue is that we expect some standard behaviour when the user
interacts with the graphics, whereas SVG contains all such code as separate
scripts.


SVG
---

The SVG specification [1] is really huge and probably way too large to implement
and be useful in a communication tool. We therefore pick the minimal
standardized set we can find, which is Tiny SVG [2] (SVGT):

<svg xmlns='http://www.w3.org/2000/svg' version='1.1' baseProfile='tiny'>

Each element must be uniquely identifiable using the id attribute.
Thus, we need to have the id attribute REQUIRED instead of IMPLIED.

There are no newlines, or they get digested. Instead it is recommended
to use the tspan element, but that does not relate the lines to each other
logically, which is need for editing etc. Therefore, I propose to use newlines
in text elements. Furthermore xml:space='preserve' must be assumed.
We also need to have a special way to handle tabs.

In the font-size style attribute, pt (points) units are allowed.
This wont work between machines of different screen resolutions.
Therefore, use user units (like pixels) for font-size.
No pt unit allowed.

There are three possible ways to design a globally unique id attribute.
It is the clients responsibilty to make sure it is unique. One possibility is 
to use a string without any particular form. (Compare GUID for COM objects.)
The second way is to use the 2-tier jid of the user and a running 32 bit
nonnegative integer number as 'marilu@jabber.dk/50327715'.
Every client is responsible for that this number is unique. This way a client
may use, say the time, to initialize this number, and then just increment
by one for each element, which should make them unique. There can be a problem
if (when) a client is using several jid's.
The third way would be to use the clients ip address instead of the jid above.


USE CASES
---------

I would suggest the following basic messaging syntax:

<message to='marilu@jabber.dk'>
    <x xmlns='http://jabber.org/protocol/svgwb'>
	<rect x='111.0' y='90.0' width='116.0' height='72.0' 
	     style='stroke: black; stroke-width: 1.0; fill: none;' 
	     id='marilu@jabber.dk/50327715'/>
	...
    </x>
</message>

In this case our added (edit) elements would end up as siblings to
the svg elements.

As an alternative I would suggest that svg and our added editing
elements be separated. Thus, our new elements would never
intrude on the svg namespace, as:

<message to='marilu@jabber.dk'>
    <x xmlns='http://jabber.org/protocol/svgwb'>
	<svg xmlns='http://www.w3.org/2000/svg' version='1.1' baseProfile='tiny'>
	    <rect x='111.0' y='90.0' width='116.0' height='72.0' 
		style='stroke: black; stroke-width: 1.0; fill: none;' 
		id='marilu@jabber.dk/50327715'/>
	     ...
	 </svg>
	 ...
    </x>
</message>

Lets keep these two options open for the moment. It depends on how we decide
to implement the editing.


EDITING
-------

Editing of a static document is made via the DOM APIs which is not applicable
in a streaming environment. There are two ways to implement an editing mechanism
in XMPP. The first way would be to just send completely new elements to replace
any existing element. The other way would be to introduce a few editing
elements that act as commands or operands on other elements.

The drawback with the former editing model is that it requires much more
bandwidth since complete elements are sent. For a large text item, or other
complex elements, this can be quite large. The latter way requires extra
elements, and thus "pollutes" the original protocol.

When it comes to edit elements I have the following suggestion, using a
simple move or translation of an element:

<configure id='...' transform='translate(30,20)'/>

Here we don't get two alternatives as above.

This command actually changes the coordinates of the element it acts upon.
The complete element with an additional scale operation would look like:

<message to='marilu@jabber.dk'>
    <x xmlns='http://jabber.org/protocol/svgwb'>
	<configure id='...' transform='scale(2) translate(30,20)'/>
	...
    </x>
</message>

This could easily be generalized to any attribute:

<configure id='...' attrList/>

where attrList is an arbitrary list of attributes that apply to
the element(s) with given id. Maybe editing elements shall not use the id
attribute to reference existing elements, but instead an xlink:href attribute:

<configure xlink:href='#marilu@jabber.dk/50327715' transform='translate(30,20)'/>

I think this is the proper way to reference an existing element
in a xml document. Additonal elements are required to delete, raise, and lower
elements:

<delete xlink:href='#marilu@jabber.dk/50327715'/>

and:

<raise id='marilu@jabber.dk/50327715' idabove='...'/>

and similarly for lower. These two latter elements changes the display 
(stacking) order for an element.

The text element requires two additional editing elements.
Insert element to add characters:

<insert id='marilu@jabber.dk/50327715' before='8'>new text</insert>

where the before attribute is REQUIRED and marks the character position where
the text shall be inserted. A dchars element deletes characters:

<dchars id='marilu@jabber.dk/50327715' first='5' last='9'/>

where the first is REQUIRED and last OPTIONAL. So six new elements are needed
for editing.


SYNCHRONIZATION
---------------

This is a large subject which has been dealt with in a separate MEMO [3].


SCRIPTING
---------

A Jabber client using whiteboarding expects some standard user interface;
that elements can be created, deleted, and edited. SVG, by default, contains
no such bindings. This is added using separate scripts. In a Jabber environment
this would require a large amount of scripts sent whenever a communication
is started. This situation would require a very large bandwidth which we
want to avoid in XMPP.

Each jabber client is responsible for adding a suitable amount of user 
interaction for each type of element. However, certain elements may need
nonstandard handling. For these elements each client is responsible to
provide the necessary script as an entity in the usual SVG way.


PLUGINS
-------

SVG handles plugins using a foreignObject element [1 Sect 23.2]. This element
hardcodes the extension to use using the requiredExtensions attribute.
In our case it is better to use a more flexible mechanism where the extension
is not hardcoded, but instead the mime type is a REQUIRED attribute of an
embed element, and the client is responsible to handle a plugin machinery where
a plugin registers for a set of mime types it handles, which similar to how 
it works in web browsers.

The childs of the foreignObject element are namespaced which allow for the
extension. An example is:

<foreignObject x='16.0' y='16.0' width='166' height='22'>
    <embed xmlns='http://jabber.org/protocol/svgwb/embed/' 
        id='foo113-120.visit.se/195216991' 
	xlink:href='file:///Users/matben/Tcl/cvs/coccinella/sounds/newmsg.wav' 
	size='45063' mime='audio/wav'/>
</foreignObject>


GROUPCHATS
----------

Groupchats create a special problem since the state of the complete whiteboard
must be kept by the conference component, and sent out to newly joined users.
This is different from ordinary text chats, where only the latest messages are
needed for the chat to make sence. This is not the case for whiteboard chats.

Two parts must be kept:

1. The elements themself

2. Binary and other external entity references

The second item is especially difficult. In principle, the MUC component could
be configured to keep an infinite history list, but with many edits this could
get very inefficient. It shouldn't be that hard to write a script that does
a "compactification", and applies all the edits to the document.

Binary entities requires some offline storage, and that the xlink:href attributes
are modified to match the offline storage uri's.

The disco category for SVG whiteboard groupchats can be conference/svgwb,
which is used for discovering whiteboard enabled rooms. This category must
not coexist with the conference/text category.


REFERENCES
----------

[1] http://www.w3.org/TR/2003/REC-SVG11-20030114/

[2] http://www.w3.org/TR/2003/REC-SVGMobile-20030114/

[3] http://coccinella.sourceforge.net/docs/MemoSyncSVG-XMPP.txt