Jean.Paoli@grif.fr
People often ask us if we know a trick for editing all those URLs which fill our documents and which keep us awake at night worrying about how to modify them all as soon as someone makes the slightest change to one of the documents - if, that is, we had managed to insert them correctly in the first place without making any typing mistakes.
Surely there is something wrong here? There is all that wonderful information out there waiting to be exploited and it seems that the only way to get at it is with a series of hacks, tricks and other assorted methods: Let us have a little respect!
The real question that we should be asking ourselves is not how to go about hacking the WWW, but how to develop an interactive tool which can recognize the different elements which make up the WWW and which will allows us to create and modify these elements interactively across the network. There is a real need for a tool to enable effective collaborative authoring of documents by people around the world. In short, a tool which will allow us to "Edit the WWW".
In this paper, we propose an approach for building an authoring tool wired on the Net. We first present in section 2 the elements which make up the WWW and which must be accessible to the authoring tool. Then, in section 3, we give an overview of the basic functions required by an authoring tool for the WWW. This basic description provides a starting point for the definition, in section 4, of a system which allows efficient cooperative editing of documents on the WWW, using a suitable user friendly interface.
From the user"s point of view, the WWW is made up of a set of files, each of which contains many links to other files stored either locally or on some remote site.
These files are stored in HTML for text and point to files describing images, graphics, video or sound, stored in a variety of popular formats (GIF, JPEG, etc).
Today, a complete document on the WWW consists of non-text files, many small text files (a few pages each) and many local or remote links which knit these files together. For example, small text files might be used to store separately the different chapters of a document, while others are used to store the document"s table of contents and index. Text files are filled with many links which describe in detail the relationship between these files. There are many links because each individual file is relatively small.
It is the coming together of these two elements (files and links) which is at the root of the WWW"s success. The user considers this collection of files and links as a single document, which he can browse interactively.
Our view is that there is no reason why the user should not be able to create a collection of files and links as a single document on the WWW in the same way and with the same ease as he is today able to browse them.
For the user, then, these distributed documents consist of the content of the local documents, plus the content of remote documents plus the links which join them all together. If a tool is to allow the user to edit documents within this framework, it must be able to recognize the different elements that the user might want to create or modify, that is all the elements which make up the WWW i.e. local files, remote files and links.
The tool must be able to recognize the structured content of documents, such as described in HTML. It must be directly wired to the network for retrieving or saving documents on remote servers and must provide the special commands necessary to recognize and manipulate anchors.
Anchors must be considered as specific elements in their own right if they are to be manipulated as such. An anchor consists of the complete set of information describing a link: the start tag ( <A> ), the end tag ( <\A> ) and the different attributes of the anchor such as the URL.
Special commands to manipulate this information, such as Create(Anchor), Copy(Anchor), Cut(Anchor), Paste(Anchor), Search(Anchor), Replace(Anchor) are needed if we are to provide the necessary high level graphical interface required by the end user. In this way, when editing a document, a user could create a link by following a few simple steps:
In the first step, the user is able to visually identify the document he wants to refer to, thus avoiding the risk of errors. This is possible because the tool is wired to the network.
In the second step, the action of selecting the document automatically provides the tool with the correct document URL as well as the identifier of the portion of the document if one was selected. Activating the menu item stores this information for further use.
In the third step, the CreateLink command encloses the selected element with the correct start and end tags and then inserts the previously stored URL reference.
As another example it would be just as easy for the user to copy an existing link and paste it onto another portion of a document:
The CopyLink command searches for the start and end tag of the anchor containing the sentence selected in step one, including the URL information but not the sentence itself.
The PasteLink command then applies the same linking information to the new item.
Just as anchors need to be manipulated as individual elements, the same applies to the other elements which make up the WWW i.e. local and remote files.
For this, the tool needs to be able to read and write both local and remote files. OpenURL and a SaveURL commands should be available to the authoring tool.
To be able to manipulate the content of these files, the tool must recognize the notion of structured documents. A good approach would be to adapt an existing SGML editor, which already uses the structure of documents, as described by a DTD, to guide the user through the authoring process. It would be necessary, however, to relax the constraints imposed on the parser by the HTML DTDs in order to be able to read existing HTML documents, created manually for the WWW.
The editor must be WYSIWYG (no "source view") and use a modern graphical environment to display documents to be edited in a clear and comprehensible format.
For all the functions described above, it is clear that the authoring tool needs to be directly wired to the WWW. How would we go about editing the WWW if we are not able to manipulate directly the different elements which make it up?
There are today a number of problems which remain to be solved. The major one concerns the problem of saving documents remotely.
Most servers are not set today to accept the PUT element of the http protocol. Security and management factors must be considered carefully before using it. As usual on the WWW, a minimalist approach has been adopted and this element is implemented on top of security setups driven by the servers. We can expect that these security features will be enhanced in the future but we can already begin using it today, at least within the internal networks of corporations.
The PUT element of the http protocol allows documents to be saved in a location specified by a URL. PUT can be enabled without recompiling the server by adding some configuration files to enable, among other things, the designation of directories on a remote server where files could be stored. The simple strategy for an authoring tool would be to fetch the last modification time of a file at load time and to send this date and the new content of the file at save time to a CGI script on the remote server. In this way, the script could compare if the file has been modified by someone else in the mean time.
Another possibility would be to use the POST element of the http protocol which is widely accepted today by most servers because this is what is used in HTML forms: Data is collected in browsers such as Mosaic and sent using POST to a CGI script on the remote server. This is how data and the original document containing the form are associated. In the same way, a remote save would never delete an existing file located in a URL location but would create a new version associated to this URL.
In the previous sections, we gave an overview of the basic functions required by an authoring tool for the WWW. This basic description provides a starting point for the definition of a system for cooperative editing of documents on the WWW i.e. for building groupware applications based on hypermedia technologies [Kaplan 92] [Neuwirth 90] [Fish 88] .
The notion of cooperative editing describes the ability of a group of authors located at different sites around the world to work together on the creation of a common document.
The task of creating a very large document, for example, might be split between a number of authors, each being responsible for one or more chapters. Each author would have the ability to edit his own chapter and to visualize and annotate the work of other members of the team.
Different cooperation strategies could be envisaged:
For all three strategies, administrative roles must be created on the network and read-only, read-write, administrator, and no-rights roles should be attached to groups of users on a fragment basis.
It is in the corporate context that we see the greatest need for collaborative working environments. In the case of an electronic components manufacturer, for example, it would not be uncommon for a group of ten or more engineers to work together on the definition of a new electronic device.
It is generally accepted that people in this kind of corporate environment often manipulate the same kind of structured information which describes very precisely the nature of their business data. This is the reason they rely on SGML.
It is essential therefore to provide the possibility for the collaborative authoring of SGML documents distributed over the WWW [Sperberg 94] .
There are four different points which have to be examined to distribute a document on the WWW:
HTML is a specific SGML DTD [Berners 94] (although there is currently a lot of discussion on this subject) but the http protocol is completely independant from this DTD and from the tags this DTD defines (this explain why the set of supported tags is evolving in the different versions of HTML). This is why using another SGML DTD which simply defines the use of another set of tags could be easily envisaged.
The last two points (linking and display) are the key points :
An easy solution to the problem of being able to point from any SGML document to any other file on the network would be to introduce the <A> anchor tag (with exactly the same definition that we find in HTML2.0) into every SGML DTD to be used on the Net. There are no technical problems preventing this.
Other easy solutions could be found by using the HyTime standard [DeRose 94] or by adding an adequate association in a DSSSL description: the important thing here is to be able to indicate to the browser or to the editor which tag of the DTD represents the start and end of the link (i.e. the tag which looks like the <A> anchor tag) and which attributes contain the URL (i.e. which attributes looks like the HREF attribute) [Paoli 94] [Quint 94].
The display of SGML tags is the most serious problem we have to consider. The display of structured information has always been recognized as difficult, mainly because structured information means management of a tree representation of a document and display means a two dimensionnal representation on screen or on paper of that tree.
The DSSSL standard, which is intended to describe stylesheets adapted to structured information in a standardized way, is at last being finalized and concrete action has already been taken (DSSSL Lite [Clark 95]) by vendors and tool builders involved in the SGML community (SGML Open) and in the WWW community (NCSA and other organisations). DSSSL Lite is intended to define a suitable subset of DSSSL which will allow the display of SGML tags for browsing purposes. This level of on-screen formatting is perfectly suitable for an SGML authoring tool wired to the WWW which could allow the use of a pageless WYSIWYG stylesheet model, well adapted to on-screen editing.
The success of a collaborative authoring tool for the WWW will clearly depend on the quality of its user interface.
It is the WWW"s Document Oriented user Interface, as used by Mosaic, that has been largely responsible for its large acceptance. For example :
In the above examples, the integration of multiple tools is done in a seamless way for the end user: data is generated within a document and sent from tool to tool, from server to server. The document is used as the natural vehicle between users and computers.
This kind of user interface is called Document Oriented user Interface (DOI): basic user operations on the document launch tools which operate distinctively on the selected portion of the document. We call this the document paradigm because complex applications could be disguised as document component behavior.
This user interface philosophy has been endorsed by major companies: Microsoft is increasingly comitted to OLE and Apple, IBM, Novell and others are creating and supporting OpenDoc. OLE and OpenDoc, although there are some differences between them, are both basically aimed at providing Document Oriented user Interfaces.
When building a document, you create or get frames and put them into a document window. When you select an element, the appropriate tool to manipulate it becomes available. You see the document as a whole in the same window but a software mechanism will distinguish mouse clicks, menus and similar features for each element. So the system chooses for you the treatment to apply, launches the right job, helps you a lot.
These environments reinforce the notion of content. Individual applications become relatively less important because many of them are used to build a single document.
Collaborative authoring tools for the WWW must develop and make extensive use of this user interface approach, providing features such as those described below:
In these examples, SGML reinforces Document Oriented user Interfaces because data are more clearly identified by semantic tags [Paoli 94] . Semantic tags are used to identify more precisely corporate or industry specific information such as motors, product parts, transistors, or other objects which require a very precise description. This is one of the strong points of SGML and there will always be a need for mission-critical data to be formalized and stored using such markup.
Because the system knows more about the data, it can more easily identify what to launch and what to help. This is why semantic SGML tags constitute the ideal fragment of information that can be produced, manipulated and exchanged over the network on the WWW by authoring tools wired to the network and based on a Document Oriented user Interface.
The technology which will allow several people around the world to work together on the creation of common documents is already well advanced.
This technology relies on the use of structured editing tools wired to the WWW.
Basic operations such as local or remote saving, linking of documents and locking or unlocking documents on the network can be already achieved using a comprehensive graphical user interface but security and protocol questions remain.
Complex cooperative strategies could be adopted and exclusive, parallel and annotation strategies could be envisaged.
SGML provides the basic data representation to allow the generalization of collaborative authoring on the WWW by large corporations. SGML fragments can navigate from server to server and one can start thinking about building virtual documents by assembling temporarily these different fragments.
Document Oriented user Interfaces provide the natural approach for building integrated environments where more and more tools and authors on the network are involved to produce documents.
GRIF S.A. and INRIA are currently working on a collaborative editing tool for the WWW.
Grif is a WYSIWYG SGML editor which allows files based on any DTD to be loaded, edited and saved in native SGML format. Functions for handling each of the different HTML versions have been incorporated into Grif and the SGML parser used has been modified so as to accept (on demand) SGML documents which are not strictly valid.
Thanks to the expandability of Grif, the WWW http library has been integrated into Grif and OpenURL and SaveURL commands have been added. Various cooperative strategies have been studied to allow collaborative authoring on the WWW and a simple strategy (lock/unlock file) has been developed.
Special user-friendly editing (click and point) commands for creating and modifying anchors have been written and links can be followed immediately after being created through the network. The tool accepts each of the HTML `dialects" and any other SGML DTD could be incorporated in the tool, using the standard features of the Grif environment. This would allow the creation, editing and remote saving of documents by multiple authors on the network in their original SGML format.
Further work is planned in the field of collaborative authoring on the WWW including the incorporation of annotated documents, handling large documents, support for different versions and the interactive incorporation of various fragments of data from different servers into one document.
URL: You can freely download the Grif HTML editor for the WWW from INRIA WWW server at http://www.inria.fr.
Acknowledgements : We would like to thank Tim Berners-Lee, Robert Caillaux, Ari Luotonen and Mario Ruggieri from MIT & CERN for their very interesting and fruitful discussions which have allowed the definition of needs for a collaborative authoring tool for the WWW. We would also like to thank Stuart Culshaw at Grif S.A. for his help in reviewing this paper.
Jean Paoli is the Technical Director and a co-founder of Grif S.A., a leader in the creation of SGML authoring tools. He supervises the development and imple mentation of Grif"s WYSIWYG SGML products, the latest being Grif SGML Editor for Macintosh and GATE, an interactive SGML API. Paoli manages Grif S.A. application consulting groups as well as research and strategic planning toward the Grif technology.
He is currently driving a joint INRIA/Grif S.A. project for the development of a WWW editor to enable collaborative authoring on the network.
Paoli draws on more than 10 years of experience in the structured editing field. Before co-founding Grif S.A., he worked on structured editors for programming languages with the leading French software house SEMA-GROUP and France"s leading computing research institute, INRIA. Jean holds his specialisation in software engineering from the Ecole Nationale des Ponts et Chaussées.