Data-layer Collaboration in Graphical and Text Authoring

Michael Fergusson
Vice-President of Product Development
Blast Radius Products
Vancouver
Canada

Biography

Michael Fergusson is an accomplished technology entrepreneur, visionary and business manager. He has more than ten years experience in web technology and product development. Michael was involved in many industry firsts in the XML and web infrastructure sectors. He founded several companies, including a unique XML-based collaboration technology enterprise that was acquired by Blast Radius in 2002. Michael continues to work on collaborative XML technologies as a Vice President in the Products division of Blast Radius.

Paul Prescod
Blast Radius Products
Vancouver
Canada
pprescod@blastradius.com
http://www.prescod.net

Biography

Paul Prescod is Director of Application Development for the products division of Blast Radius. Paul is well-known in the XML community as a standards advocate, software developer and writer.


Abstract


SVG is one of a few emerging standards with the potential to make major inroads onto the desktops of ordinary users and into the toolbox of ordinary programmers. As such, it is inherently an important communication and collaboration technology. But the fact that it is XML also enables it to partake in a new revolution of collaboration techniques available specifically to XML-described data.


Table of Contents


The Role of Collaboration
SVG's role in collaboration
Blast Radius collaboration platform
Data-Contextual collaboration
SVG Whiteboard on the DDOM
Collaborative graphic creation
SVG in Model-View-Controller collaboration
SVG as an application view
Conclusions

The Role of Collaboration

The Internet is fundamentally about communicating. First and foremost, it helps people communicate with people, but it also used for automated systems communicating with each other. Collaboration is a specialized form of communication. Merriam-Webster defines it as "to work jointly with others or together especially in an intellectual endeavor". Collaboration is goal-oriented whereas communication is not always so. So you can communicate about recipes but you would collaborate on the production of a cookbook. You can communicate by sending someone an SVG map of a subway system but you would collaborate on the creation of an SVG subway system map.

When a group of knowledge workers collaborate, they are usually working together to produce some concrete deliverable. It might be a prose document, graphic, or spreadsheet. They tend to think of each other as peers. They are often strapped for time. They move fluidly from working separately, in parallel, to working together, in real-time. A collaboration tool is thus distinguished from a communication tool through its focus on the completion of tasks and the achievement of goals.

The collaboration industry is moving towards consensus that the best kind of collaboration is contextual collaboration. Contextual collaboration situates the collaboration in the context of the user's work. But what this means in practice can vary radically. It is possible to take a totally non-contextual collaboration mechanism like chat and stick it into an application but this is only a baby step.

Blast Radius Products believes that most collaboration products miss out on an important opportunity to collaborate in the context of data objects. This paper will describe how SVG could benefit from a generic solution to this problem and could in turn complement the solution.

SVG's role in collaboration

SVG is one of the most important in a family of standards that will allow Internet-based communications to be much richer in the future than they have been thus far. Clearly, it will revolutionize the Web, making it much more efficient, interactive, easy to program to and device-scalable. It fills an important gap: as they say, a picture can be worth a thousand words.

SVG is ultimately a communications technology. It is used for communicating graphical ideas and visualizing data. As such, SVG is often used in collaboration contexts. But we feel that it should also be explicitly added to the collaboration toolbox. SVG allows data to be componentized and assembled so that work can be delegated and work products integrated. SVG data is very easy to manipulate programmatically and thus easy to integrate into collaborative applications. Most important: SVG is the standard format for an important class of information that people need to collaborate on: images. Businesses have been launched based on diagrams from whiteboards and napkins. Collaborative SVG would allow the napkin to span continents.

In addition, collaboration packages could allow SVG diagrams (whether created collaboratively or not) to be embedded, layered and otherwise integrated into other data objects. Finally, they might use SVG as an implementation technology for visualizing the underlying data that is the topic of collaboration. The user might not know that SVG is involved at all.

These are all interesting possibilities and could be implemented in a collaboration system designed for working with XML. This paper will describe one under development by Blast Radius Products.

Blast Radius collaboration platform

The Blast Radius collaboration platform consists of two layers. At the core is a real-time XML middleware engine called the Distributed DOM (DDOM). The DDOM is unique middleware that routes mutation events between a central, canonical document object and multiple remote client copies of it. The DDOM handles issues like locking, node identity management, change collision avoidance and event notification. It is a good basis for a collaboration platform because it allows multiple content creators to have a real-time view of the current state of the data. Nevertheless, the DDOM platform is generalized real-time data sharing platform that can be used outside of content creation contexts. For instance, it could be used as a real-time financial data broker or a way of having Web pages that keep themselves in sync with a data source.

On top of the DDOM is a collaboration layer called "Dominion" that manages collaborative objects such as annotations, links, chats, discussions, tasks, events and content objects. Dominion is designed to be integrated with other internal systems such as project management, content management and calendaring software but also provides basic implementations of all features so that the system has no dependencies. In addition, there are a variety of graphical components such as Web-based chat, discussion, presence, notification and invitation widgets.

Both server-side layers are implemented on top of J2EE. Client-side applications may be implemented in JavaScript, Python, Java or any COM-compatible language.

Data-Contextual collaboration

The Blast Radius collaboration platform was designed in response to the limitations of the pre-existing collaboration environments. Fundamentally what differentiates it from the others is that the Blast Radius platform always uses the data as the context of collaboration and is oriented around our understanding of the tasks that various authors need to accomplish with that data.

In contrast, the three primary classes of tools available today do not use data as the communication context:

  1. Desktop and application sharing tools (like NetMeeting and WebEx) allow multiple people to share a view of a software application or desktop interface. Because there is only one shared interface, only one person can modify the data at a time. For instance, it is impossible for two different people to work on different parts of a spreadsheet or prose document.
  2. Workspace sharing tools (like Groove and eRoom) allow multiple people to share files and communicate about them. They make it easy to share the data but typically only as opaque content objects. Once again, only one person can modify the data at a time.
  3. Communication tools (like IM clients or discussion groups) allow multiple people to converse but provide no real context about the topic of their conversation. For instance, Consider Enterprise Instant Messaging. Yes, you can send messages, but what are you sending messages about? Usually it is some document (textual or graphical) under development. But where is that document represented in the interface?

In a business setting, users are always communicating about some shared project and are often communicating about some specific deliverable such as a spreadsheet, prose document or graphic. Existing tools are not architected to use the deliverable as the context of the collaboration. This causes them to miss the key feature that users want. Users want to be able to work together on the same deliverable data object. In existing tools this data object is secondary or even non-existent. In our vision, this object is the primary focus.

We feel that users do not just want to share a view of the data, nor email the data back and forth, nor segment the data into arbitrary chunks that must later be pasted together. They want to work together on the data, with all parts in context.

Users also do not want to be forced into unnatural collaboration models. Sometimes they will be happy to talk back and forth in real-time. Other times, they will want to work separately on different portions of the data object without interfering with each other. This implies a couple of things for the user interface. It must inform them when other users do something that may affect them (e.g. change a spreadsheet cell that will affect a calculation that they depend upon). It must be able to report what has changed in the document since the last time they were interested. It must help them to find and manage reusable content objects.

SVG Whiteboard on the DDOM

The DDOM can work with any XML vocabulary but our focus is on content authoring vocabularies such as DocBook, MathML and of course SVG. The first SVG application we built on the system was a whiteboard. This was a simple, easy to understand collaborative SVG application. We started with the source code for the Adobe SVG Draw demonstration application running in the Adobe SVG viewer. Essentially we wanted to attach our DDOM to the fragment of the Adobe SVG DOM that represents the document canvas and keep the two in sync.

In order to implement this, we first need to put the SVG data for the canvas on the DDOM server. This gives all clients a common view of the data and allows the canvas to be persisted for days or weeks, even if all clients have shut down. Next we need to to include the DDOM client in the SVG Draw application and connect to the DDOM server. This is easily done with a few lines of Javascript. The next step is to import the canvas data from the DDOM client into the SVG DOM. The collaborative whiteboard cannot presume that the canvas starts empty. Sessions can persist arbitrarily long and have arbitrary numbers of clients connecting and disconnecting.

Once a client is connected, we must ensure that local changes are reflected on remote client desktops through the DDOM server. In order to do this, we trap all canvas change events and route them to other participants on other clients. One challenge in implementing the system is that the Adobe SVG viewer does not support proper mutation events. We have found that this limitation is common in DOM implementations. This necessitates deeper changes to the application. Any time it changes its own DOM, we must change the code so that it changes ours instead. In a slightly more capable scripting language (e.g. Python) we could have made a wrapper object that exported the DOM interface but notified our DDOM as a side effect. We look forward to a future where DOM mutations are available so that we can implement more elegant and concise integrations.

It is comparatively easy to integrate changes from the network into the local canvas. We can merely reflect the change into the local DDOM by mapping (e.g.) insertion events to insertBefore method calls, attribute change events to setAttribute calls and so forth.

Overall, integrating SVG with our DDOM technology was relatively painless compared to the difficulty we would have encountered with non-DOM technologies like CGM or Flash.

Collaborative graphic creation

A whiteboard is a useful tool for doing "napkin diagrams" and it is quite impressive that with only a few lines of code we can have a napkin that works across the Internet. But this is just a start. Developing appropriate tools for data-level collaboration always requires an understanding of how people generate, manipulate and manage data objects and how they would like to do these tasks collaboratively. Professional graphic designers do not work on whiteboards for anything more than initial sketches. After that, they want a full drawing program with all of the features they have come to expect over the years. They also want to work with much more structured objects than the box and circle primitives available in a whiteboard. We have not yet integrated with a full drawing program but we have given some consideration of what such an integration might look like.

Obviously a collaborative professional drawing tool should be a superset of the whiteboard. It should be easy for two people to work together in real-time on a graphic. But it is just as important, if not more important, for professionals to collaborate across long stretches of time. This implies that a complete collaboration system must allow storage, management and browsing of SVG components. Any content management system allows the attachment of metadata but a collaboration system should allow collaborative artifacts to be attached. These could be discussions, wikis, chat transcripts or even live chat rooms. Or, in fact, they could be other SVG diagrams.

This points the way to another important use of SVG in a collaborative setting. SVG documents can be associated with other content in order to illuminate or illustrate them. In particular, SVG can be used as an overlay in the form of pen-input "digital ink".

SVG in Model-View-Controller collaboration

SVG documents are XML documents that describe how to display something. But SVG can also be generated from XML data sources corresponding to arbitrary vocabularies representing anything from family trees to friendship relationships to numerical data. The DDOM can also be used to share this data in real-time. The benefit of sharing the underlying data rather than the view is that each client can choose its own most appropriate view. The same data could be presented to one user as a bar-chart, to another as a pie chart and to another as a table of numbers. This is one of the key advantages of implementing collaboration using data sharing rather than view sharing.

They key to a shared data model is a widely implemented standard. The DOM provides standard notions of object, containment and events. Specifications layered on top of the DOM provide the tree syntax and semantics specific to a particular domain. For instance if you distribute XBRL data through a DDOM then you have a real-time financial information distribution platform. If you distribute SVG, then you have a real-time graphical information distribution platform. Because the platform is based upon standards,

In order to implement the SVG version of model sharing, we create a Web page with a reference to a DDOM and an embedded SVG viewer. Javascript functions translate XML elements and values into SVG. If the system is to be high performance, the Javascript must be designed so that it only updates the appropriate subset of SVG rather than the whole document. This takes some thought. For instance, each element in a bar chart is individual but all of the elements in a pie chart depend on the values for all of the rest.

Depending on how elaborate the "Rendering Arbitrary XML" (RAX) feature is in SVG 1.2, it might be handle some of the mapping for us instead of using Javascript. It will be important to watch whether RAX is designed to allow real-time mutations to the arbitrary XML to be reflected in the SVG in an intelligent way. It might be tricky for the SVG viewer to detect which graphical elements depend on which XML elements. But it would be quite inefficient to recalculate everything every time an element changed. This is an interesting problem to be investigated in the implementation of SVG viewers. We would love to have the viewer handle it rather than doing it ourselves.

SVG as an application view

There are many applications that allow one user to see exactly what another user sees on their desktop or in an application. Examples include NetMeeting, VNC or WebEx. These applications are incredibly useful in a variety of circumstances, from technical support to software demonstrations. The only problem is that the protocols that they use tend to be application-specific and frame-buffer (bitmap) oriented. Modern desktops are increasingly vector-oriented and it would make sense for future protocols to work at this level. As an intellectual exercise we conjecture that a future standard for these programs could be built on top of SVG and the DDOM. It would actually be quite straightforward at the protocol layer. Essentially the vector-based GUI (dare we dream of an SVG-based GUI?) would transmit changes to the remote views merely by manipulating an SVG DOM. For example, when a user clicked an icon to create a new window, the window could be represented in the SVG DOM as a box. Multiple people could even interact with the desktop through the selective interpretation of DOM GUI events.

Conclusions

To be widely useful, collaboration must be driven into the heart of every content creation application. Just as it is becoming common for applications to have the ability to read and write data directly to the Web, it must become possible for them to work directly in a collaborative environment. This implies that the collaboration environment must either be a standard platform like the Web or, more likely, a standards-based extension to the Web. Standards are the only way to solve the current situation where people using one collaboration platform (e.g. Groove) cannot communicate with another one (e.g. NetMeeting). Furthermore, the data that is being collaboratively shared must be in standardized formats like SVG and XHTML or else users will be limited to collaborating with only people who use the same authoring application. SVG is likely to be the key enabler of standards-based graphical collaboration.

XHTML rendition created by gcapaper Web Publisher v2.0, © 2001-3 Schema Software Inc.