[Standards] whiteboarding and shared editing

Peter Saint-Andre stpeter at jabber.org
Thu Aug 16 21:39:47 UTC 2007

Bishop, Michael W. CONTR J9C880 wrote:
>> Requirements, requirements, requirements. Again, it would help for
>> someone to write a clear and comprehensive requirements doc.

OK I have re-read the three whiteboarding-related proposals:


As well as Mats's sync memo:


And the collaborative data objects spec contributed by MITRE:


I have also re-read some email messages sent both on-list and off-list
(e.g., some discussion that Ian Paterson, Joonas Govenius, and I had in
January about synchronization requirements).

So I hope that I can add helpfully to the requirements discussion. :)

I will send out another message in a new thread with a summary of the
requirements as I see them based on my reading.

>> It would also help for you to summarize the ways in which
> whiteboarding
>> is more than modifying an XML document. That would help us find common
>> ground and achieve consensus.
> While I don't have a requirements doc, I can share the problems we tried
> to solve with our whiteboarding approach we recently submitted:
> - The editing of shared XML documents.

As others have mentioned, this seems to be the basic synchronization

> - Logical ordering of said shared documents.

I'm not sure what exactly you mean by that. Do you mean that documents
need to be edited or presented in a specific order? Examples might be to
enable a workflow of collaborative data objects (XEP-0204) or a series
of XHTML documents in a presentation (think S5). To me this seems like
something that we'd build on top of the shared editing protocol in order
to bundle documents together.

> - Presentation. (Page changes and a future revision to support cursor
> position.)

I can see that communication of cursor position might be helpful in
certain contexts, but I think that this would be optional. It's kind of
like Chat State Notifications (XEP-0085) for shared editing, in a way,
since it provides information about the state of the participants, not
state about the data being exchanged in the stanza session itself (where
I use the term "stanza session" as an abstraction from chat session in
XMPP messaging, whiteboard, shared document, etc.).

> - Roles.  (Who can edit?  Who can only observe?)

I agree that this may be needed in larger groups, but it is probably not
needed in 1-to-1 mode or in small/informal MUC rooms.

> - Current state.  A user can join and get the current state.

Yes, this is common across several of the approaches.

> - History.  A user who got disconnected can rejoin and ask for the last
> X actions to occur.

This may be a subset of getting the current state.

>> If someone takes time and look into http://coccinella.im/memo/sync
> they will see that it is completely
>> generic and general. There is nothing specific to whiteboarding and it
> could be used in any context where
>> the basic assumptions are valid.
> While reading some of the discussions on this topic in the list, I
> realized that our protocol shares some of the same characteristics.
> While it was designed specifically for whiteboarding using SVG as a
> medium, the protocol itself does not deal with SVG.  The manipulation of
> the SVG document can be applied to any XML in any namespace.  While it's
> been written as a whiteboard protocol, nothing forces it to be one.  It
> would work as-is as a shared XML document protocol with permissions,
> history, current state, and presentation.

Very interesting. We seem then to be converging on consensus about what
should be possible here. That is, it should be possible to develop an
approach to shared XML editing that enables us to edit different XML
formats, such as SVG, XHTML, and collaborative data objects (XEP-0204).

> Peter wrote:
>> Greg Hudson wrote:
>>>> On Mon, 2007-08-13 at 22:30 -0600, Peter Saint-Andre wrote:
>>>>>> I see nothing artificial about trying to build a generalized 
>>>>>> approach that we can re-use for shared editing and real-time 
>>>>>> synchronization of a wide variety of XML formats, not just SVG.
>>>> I don't know if it's "artificial" or not, but "you should go back 
>>>> and solve a much more general and more vaguely defined problem" is 
>>>> generally a good way to kill a project.
>>>> A generic XML editor isn't going to know much about the semantics 
>>>> of the document it is editing.  It's not necessarily going to be a 
>>>> good framework for a whiteboarding application, any more than emacs
>>>> is a good foundation for Photoshop.  They both edit files, but...
>> I don't think anyone is arguing for a general *application* that would
>> do shared XML editing that would do whiteboarding, spreadsheets, word 
>> processing, presentations, and everything else under the sun. But it 
>> seems wasteful for us to define separate XML editing/syncronization 
>> protocols for each application type, unless there really are special 
>> considerations that make it is impossible to use the same underlying 
>> technology for each. Which is what we're talking about taking some 
>> time to explore...
> If someone takes time and look into http://coccinella.im/memo/sync they
> will see that it is completely generic and general. There is nothing
> specific to whiteboarding and it could be used in any context where the
> basic assumptions are valid.
> However, the basic assumptions imply that we haven't dealt with editing
> parts of CHDATA or parts of attributes, but elements are treated as
> entities.
> Mats

Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7354 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20070816/482a4cb4/attachment.bin>

More information about the Standards mailing list