`
`Exhibit 1018
`Unified Patents v. Synkloud Technologies
`Page 001
`
`

`

`Proceedings of the
`Sixth European Conference on
`Computer Supported Cooperative Work
`
`

`

`ECSCW'99
`
`Proceedings of the
`Sixth European Conference on
`Computer Supported Cooperative Work
`12-16 September 1999, Copenhagen, Denmark
`
`Edited by
`Susanne Bjijdker
`University of Aarhus, Denmark
`
`Morten Kyng
`The Danish National Centre for IT Research, Denmark
`
`and
`
`Kjeld Schmidt
`Technical University of Denmark, Denmark
`
`Cover Design by lette Guldfeldt, Graphix
`
`SPRINGER-SCIENCE+BUSINESS MEDIA, B.V.
`
`

`

`Library of Congress Cataloging-in-Publication Data
`
`ISBN 978-0-7923-5948-7
`
`ISBN 978-94-011-4441-4 (eBook)
`
`DOI 10.1007/978-94-011-4441-4
`
`Printed on acid-free paper
`
`AII Rights Reserved
`© 1999 Springer Science+Business Media Dordrecht
`Originally published by Kluwer Academic Publishers in 1999
`
`No part of the material protected by this copyright notice may be reproduced or
`utilized in any form or by any means, electronic or mechanical,
`including photocopying, recording or by any information storage and
`retrieval. system, without written permission from the copyright owner.
`
`

`

`Table of Contents
`
`From the Editor
`ECSCW '99 Conference Committee
`ECSCW '99 Program Committee
`
`Taking the work out of workflow: Mechanisms for document-
`centered collaboration
`Anthony LaMarca, W. Keith Edwards, Paul Dourish,
`John Lamping, Ian Smith, and Jim Thornton (Xerox
`PARC)
`
`The Manufaktur: Supporting work practice in (landscape)
`architecture
`Monika Buscher (Lancaster Univ.), Preben Mogensen
`(Univ. of Aarhus), Dan Shapiro (Lancaster Univ.), and
`Ina Wagner (Vienna Technical Univ.)
`
`Six roles of documents in professionals' work
`Morten Hertzum (Ris¢ National Laboratory)
`
`AREA: A cross-application notification service for groupware
`Ludwin Fuchs (Boeing Mathematics and Computing
`Technology)
`
`Moving out of the meeting room: Exploring support for mobile
`meetings
`Jens Bergquist, Per Dahlberg, Fredrik Ljungberg
`(Viktoria Institute); and Steinar Kristoffersen (Norwegian
`Computing Centre)
`
`Activity Awareness: Framework for sharing knowledge of
`people, projects, and places
`Koichi Hayashi, Tan Hazama, Takahiko Nomura,
`Toshifumi Yamada (Fuji Xerox); and Stephan
`Gudmundson (Univ. of British Colombia)
`
`The properties of mixed reality boundaries
`Boriana Koleva, Steve Benford, and Chris Greenhalgh
`(Univ. of Nottingham)
`
`IX
`Xl
`XU
`
`21
`
`41
`
`61
`
`81
`
`99
`
`119
`
`

`

`vi
`
`The adoption and use of BABBLE: A field study of chat in the
`workplace
`Erin Bradner (Univ. of California at Irvine);
`Wendy A. Kellogg and Thomas Erickson (IBM T.J.
`Watson Research Center)
`
`Meeting at the desktop: An empirical study of virtually
`collocated teams
`Gloria Mark (GMD-FIT), Jonathan Grudin (Microsoft
`Research), and Steven E. Poltrock (Boeing Co.)
`
`Broadcasting on-line social interaction as inhabited television
`Steve Benford, Chris Greenhalgh, Mike Craven (Univ. of
`Nottingham); Graham Walker, Tim Regan, Jason
`Morphett (BT Laboratories); John Wyver (Illuminations
`Television); and John Bowers (Royal Institute of
`Technology)
`
`A groupware's life
`Volkmar Pipek and Volker Wulf(Univ. of Bonn)
`
`The network communities of SeniorNet
`Elizabeth D. Mynatt (Georgia Institute of Technology),
`Annette Adler (Xerox PARC); Mizuko Ito, Charlotte
`Linde (Institute for Research on Learning); and Vicky L.
`O'Day (Univ. of California at Santa Cruz)
`
`GestureLaser and GestureLaser Car: Development of an
`embodied space to support remote instruction
`Keiichi Yamazaki, Akiko Yamazaki (Saitama Univ.);
`Hideaki Kuzuoka, Shinya Oyama (Institute of
`Engineering Mechanics and Systems);
`Hiroshi Kato, Hideyuki Suzuki (NEC Corp.);
`and Hiroyuki Miki (Oki Electric Industry Co.)
`
`Exploring support for knowledge management in mobile work
`Henrik Fagrell, Fredrik Ljungberg (Viktoria Institute);
`and Steinar Kristoffersen (Norwegian Computing Centre)
`
`139
`
`159
`
`179
`
`199
`
`219
`
`239
`
`259
`
`

`

`Dynamics in wastewater treatment: A framework for
`understanding formal constructs in complex technical settings
`Olav W Bertelsen and Christina Nielsen (Univ. of
`Aarhus)
`
`WebDA V: A network protocol for remote collaborative
`authoring on the Web
`E. James Whitehead, Jr. (Univ. of California at Irvine),
`and Yaron Y. Goland (Microsoft Corp.)
`
`Informing collaborative information visualisation through an
`ethnography of ambulance control
`John Bowers (Royal Institute of Technology) and David
`Martin (Univ. of Manchester)
`
`Moving document collections online: The evolution of a shared
`repository
`Randall H. Trigg, Jeanette Blomberg, and Lucy Suchman
`(Xerox PARC)
`
`PSI: A Platform for Shared Interaction
`Kevin Palfreyman, Tom Rodden, and Jonathan Trevor
`(Lancaster Univ.)
`
`An experiment in interoperating heterogeneous collaborative
`systems
`Prasun Dewan (Univ. of North Carolina) and Anshu
`Sharma (Oracle Corp.)
`
`NESSIE: An awareness environment for cooperative settings
`Wolfgang Prinz (GMD-FIT)
`
`Meaning-making across remote sites: How delays in
`transmission affect interaction
`Karen Ruhleder (Univ. of Illinois) and Brigitte Jordan
`(Xerox PARC)
`
`Augmenting the workaday world with Elvin
`Geraldine Fitzpatrick, Tim Mansfield, Simon Kaplan,
`David Arnold, Ted Phelps, and Bill Segall (Univ. of
`Queensland)
`
`Index of Authors
`
`vii
`
`277
`
`291
`
`311
`
`331
`
`351
`
`371
`
`391
`
`411
`
`431
`
`451
`
`

`

`S. BgJdker, M. Kyng, and K. Schmidt (eds.). Proceedings of the Sixth European Conference on
`Computer-Supported Cooperative Work, 12-16 September 1999, Copenhagen. Denmark
`© 1999 Kluwer Academic Publishers.
`
`291
`
`WebDAV
`A network protocol for remote collaborative authoring
`on the Web
`E. James Whitehead, Jr.t & Yaron Y. Golandt
`tDept. of Info. and Computer Science, U.C. Irvine, USA, ejw@ics.uci.edu
`*Microsoft Corporation, Redmond, W A, USA, yarong@microsojt.com
`
`Abstract. Collaborative authoring tools generate network effects, where each tool's value
`depends not just on the tool itself, but on the number of other people who also have
`compatible tools. We hypothesize that the best way to generate network effects and to
`add collaborative authoring capability to existing tools is to focus on the network protocol.
`This paper explores a protocol-centric approach to collaborative authoring by examining
`the requirements and functionality of the WebDAV protocol. Key features of the protocol
`are non-connection-oriented concurrency control, providing an upward migration path for
`existing non-collaborative applications, support
`for remote manipulation of
`the
`namespace of documents, and simultaneous satisfaction of a wide range of functional
`requirements.
`
`Introduction
`
`Despite many compelling research examples of collaborative authoring, so far
`their impact on actual authoring practice has been limited. While BSCW (Bentley
`et al., 1997) and HYPER-G (Maurer, 1996) have developed communities of use,
`electronic mail remains the dominant technology used for collaborative authoring,
`mainly due to its ubiquity.
`In order to perform collaborative authoring, all collaborators need to use
`compatible authoring tools-typically all collaborators use the same tools, tailor-
`made to support collaboration. To collaborate using PREP (Neuwirth et al., 1994),
`all collaborators need to use PREP, likewise for GROVE (Ellis et al., 1989) and
`
`

`

`292
`
`DUPLEX (Pacull et al., 1994) ..
`The economics of compatibility drive network effects (Rohlfs, 1974), where
`the utility of each tool depends not just on the tool itself, but on the number of
`other people who also own compatible tools. If there were just one telephone in
`the world, its utility would be small, with two or three not much more useful. But
`when millions, or hundreds of millions of people own telephones, their utility is
`immense. Like the telephone, one collaborative authoring tool by itself has
`limited collaborative value, but when millions have compatible collaboration
`technology, the utility of each tool is great. When a common network protocol
`ensures interoperability between collaborative authoring tools and authoring
`servers, as each tool adopts the protocol, the value of servers that support the
`collaboration protocol increases, since without any further investment in the
`server, they can now support an additional tool. The reverse is true as well. As
`more servers become available, the value of the authoring tools increases without
`any further investment in the tools, since there are now more individuals and
`organizations capable of collaboration. By creating a network protocol with a
`focus on interoperability, it is possible to generate network effects among
`compatible collaborative authoring technologies.
`Users of existing applications have invested significant time in gaining
`expertise in the applications they frequently use, hence the cost to users of
`switching to another tool is high. Yet users must switch tools to gain the
`advantages of existing collaborative authoring systems. Exceptions to this rule are
`BSCW and MESSIE (Sasse and Handley, 1993), which leverage standard
`network protocols to allow the use of existing non-collaborative tools with the
`system; the Hypertext Transfer Protocol, HTTP, (Fielding et al., 1997) is
`employed this way by BSCW, while MESSIE piggybacks on the Simple Mail
`Transfer Protocol (Postel, 1982). CONTACT (Kirby and Rodden, 1995) also
`supports collaborative authoring while
`remaining compatible with
`the
`heterogeneous non-collaborative tools in the user's environment. Like BSCW,
`CONTACT provides a Web forms interface to a collaboration support system, but
`does not provide BSCW's HTTP upload/download support. BSCW, MESSIE,
`and CONTACT share our view that collaborative authoring capability is not, by
`itself, sufficient to overcome the costs of switching authoring tools. Unlike these
`systems, we go further and assert that collaborative authoring capability must be
`added to existing tools.
`Our hypothesis is the best way to generate network effects and to add
`collaborative authoring capability to existing tools is to focus on the network
`protocol, the mechanism by which collaborative tools communicate. There are
`many reasons for focusing attention on the network protocol that underlies a
`remote collaborative authoring system. From a technical viewpoint, focusing on
`the network protocol elevates the protocol's behavior across the Internet to a first-
`class concern. This ensures that thorny issues are addressed up-front, such as how
`
`

`

`293
`
`to ensure efficient behavior under high-latency conditions, the provision of
`adequate security and authentication, and giving the protocol good scalability and
`extensibility characteristics. If addressed poorly, these factors can cripple the
`widespread adoption of a remote authoring technology.
`The Web Distributed Authoring and Versioning (WEBDAV) working group of
`the Internet Engineering Task Force (IETF) has adopted this protocol-centric
`approach, and developed a novel network protocol, the WEBDA V DISTRIBUTED
`AUTHORING PROTOCOL (hereafter called the WEBDA V protocol), which supports
`interoperable remote, asynchronous, collaborative authoring. The WEBDA V
`protocol, a detailed specification of which can be found in Goland et al. (1999), is
`a set of extensions to HTTP which provide facilities for concurrency control,
`namespace operations, and property management. The protocol allows users to
`collaboratively author their content directly to an HTTP server, allowing the Web
`to be viewed not just as a read-only way to download information, but as a
`writeable, collaborative medium.
`IETF protocol specifications foster interoperability by providing a concrete
`specification used to develop multiple applications. Indeed, for a specification to
`advance along the standards track within the IETF, it must demonstrate two
`interoperable implementations of every protocol feature. This requirement,
`combined with the group review process within the IETF, works to ensure that the
`semantics of the protocol are precise. Furthermore, the focus on interoperability
`across many applications helps limit the likelihood that the concerns of anyone
`program will bias the protocol's design.
`Since IETF specifications can be retrieved free of charge, and there are no
`licensing fees for using IETF technology, IETF network protocols are very
`attractive to both corporate and open-source developers. This freedom of the
`intellectual property rights aids in the adoption of the protocol by a wide variety
`of tools.
`One use scenario for the WEBDA V protocol is collaborative authoring of an
`academic paper by a geographically dispersed authoring team. When the project
`begins, one member of the project uses server-specific mechanisms to create
`username/password pairs for each collaborator, and then creates the shared
`document with a WEBDA V -enabled word processor by saving it to a URL. After
`giving each collaborator write access, they communicate the URL of the
`document to the rest of the team using email, or perhaps in a teleconference. The
`authors
`take
`turns working on
`the document, using email,
`telephone
`conversations, and other out-of-band communications to negotiate editing slots.
`During each editing pass, an author loads the document from the URL, causing it
`to be locked. They then work within the editor, saving directly back to the URL.
`When done, they perform a final save to the URL, then unlock the document. At
`all times, other authors can load the document directly from the URL using either
`their word processor (it will be read-only if locked) or their Web browser (if it
`
`

`

`294
`
`can view the word processor format), to see its current status. When done, they
`can give the URL to colleagues interested in the paper, and create hyperlinks to
`the paper in other Web pages.
`This paper reports on the WEBDA V protocol, presenting the requirements it
`satisfies, and how these requirements, combined with the constraints of operating
`in the Internet environment, guided its design. Key contributions of the WEBDA V
`protocol include:
`Protocol focus: The focus of this work is a network protocol, the abstractions
`and semantics which inform the syntax of octets transmitted during a TCPIIP
`connection. This contrasts with existing work on remote collaborative authoring
`which focus on user interface, awareness, and other concerns.
`Providing an upward migration path for existing non-collaborative
`applications: There are many applications that have no support for remote
`collaborative authoring. The WEBDA V protocol provides these applications a
`way to add remote authoring support without dramatically modifying the input
`processing of the application, as would be necessary if the application were
`modified to support fine-grain synchronous authoring. Furthermore, its grain size
`for concurrency control is compatible with most existing file-oriented tools.
`Non-connection-oriented protocol for concurrency control: The WEBDA V
`protocol provides long-duration exclusive and shared write locks, a well-known
`concurrency control technique. To achieve robust Internet-scale collaboration,
`where network connections may be disconnected arbitrarily, and for scalability,
`since each open connection consumes server resources, the duration of WEBDA V
`locks is independent of any individual network connection.
`Support for remotely manipulating the namespace of documents: The
`WEBDA V protocol provides copy and move operations, and provides support for
`listing the members of Web collections, similar to a directory listing in a file
`system. Though these operations have appeared before in numerous systems, their
`appearance in remote collaborative authoring systems is unusual, reflecting the
`awareness that these systems need to provide mechanisms for navigating to the
`document which will be authored, and for maintaining logical groupings of
`documents in collections.
`Simultaneous
`satisfaction of requirements: The WEBDA V protocol
`simultaneously satisfies a wide range of difficult requirements, a non-trivial
`engineering activity in which tradeoffs amongst goals impacted the protocol.
`WEBDA V addressed several concerns which are critical to adoption of a remote
`collaboration technology, but which are either not mentioned, or not addressed in
`the collaborative authoring literature, including connection security, strong
`authentication,
`internationalization,
`and
`independence
`from
`authoring
`environment. While WEBDA V benefited by adopting existing technologies such
`as Transport Layer Security (TLS)
`(Dierks and Allen, 1999), Digest
`Authentication (Franks et al., 1997), and XML (Bray et al., 1998), the
`
`

`

`295
`
`identification of the requirements, and the integration of these technologies to
`satisfy those requirements is unique.
`Extensibility: The WEBDA V protocol recognized that it would not be able to
`address all features that an authoring system would need. Thus extensibility
`became a critical feature. The protocol has been designed with well defined
`feature namespaces that allow for new features to be added later on. Existing
`systems will always be able to recognize new commands and have sufficient
`information to determine if they should ignore the unknown command or fail.
`The remainder of this paper presents requirements for remote collaborative
`authoring of Web content, then describes the WEBDAV protocol and how it meets
`these requirements. The key attributes of the WEBDA V protocol, discussed in the
`Introduction above, will be expanded in this section. Following sections will
`briefly describe the existing servers and clients that implement the WEBDA V
`protocol, and discuss the WEBDAV protocol in relation to other existing work.
`
`Requirements in support of collaboration
`
`Requirements given below are an abridged version of those found in Slein et al.
`(1998), the consensus requirements document of the WEBDA V working group.
`
`Equal support for all content types
`
`The Web is composed of documents, images, and objects of many content, or
`Internet media types (Freed et al., 1996). A Web authoring protocol must treat all
`content types equally.
`A Web authoring protocol which only provides operations for resources of
`one preferred content type, such as HTML, or which requires authoring-specific
`limited
`to support features such as versioning, would have
`extensions
`applicability due to its lack of support for the wide variety of other content types.
`Furthermore, since many common content types are in constant evolution, in
`order to ensure stability of the protocol a strict separation between the protocol,
`and the format of the objects operated upon by the protocol, must be maintained.
`For example, during the development of the WEBDA V protocol itself, new
`standards for HTML 3.2, 4.0, and XML were issued, highlighting how quickly
`these document formats can develop and evolve. Tailoring an authoring protocol
`too closely to anyone content type would rapidly make the protocol obsolete.
`
`Concurrency control support
`
`Since the Web is inherently multi-user, a Web authoring protocol must mediate
`concurrent access by multiple authors.
`Early Web authoring tools encountered the "lost update problem" which
`
`

`

`296
`
`occurs when two or more simultaneous authors of a Web page clobber each
`other's work with successive saves to the same URL, without first merging
`changes by other authors. Although HTTP 1.1 added support for detecting lost
`updates through the use of unique identifiers associated with the document state,
`no support was provided for preventing lost updates in the first place.
`Early on, WEBDA V decided to use long duration, whole resource locking as its
`concurrency control mechanism (the rationale for this choice is discussed in the
`section on Locking). This then allowed the WEBDA V requirements to focus on
`desired properties of locks:
`Lock independence: the lock operation must be independent of other
`operations. For example, it should not be necessary to retrieve the resource to
`lock it (e.g., as would be the case with a GET with lock operation). The primary
`motivation for this requirement is to maintain a separation of concerns between
`locking and other HTIP operations.
`Multi-resource locking: the protocol must support an atomic operation to lock
`multiple resources on the same server. Documents often consist of many separate
`files. For example, Web pages are composed of text, images, and executable
`content stored as separate Web resources. Hence an authoring tool needs the
`ability to prevent lost updates on all the components of these multi-part
`documents, so the document can be authored as a unit. A multi-resource lock
`guarantees this. The atomicity restriction ensures that if two people are trying to
`lock the same group of resources, only one will be granted a lock.
`Write locks: the protocol is only required to support a write lock, and no read
`lock is necessary (or provided by the WEBDAV protocol). On the Web, by default
`a resource is readable, although it may be protected by access control. Therefore,
`HTTP does not require that a Web browser obtain a lock in order to read a
`resource, as is the case with traditional database locking, and retrofitting the Web
`with this capability was not feasible, or desirable.
`Lock discovery: it must be possible to discover whether a resource is locked.
`This allows a user interface to be constructed which indicates whether a resource
`is locked.
`
`Support for properties (metadata)
`
`Since there is a significant amount of information about Web resources which is
`not directly stored in the contents of the resource, a Web authoring protocol must
`provide facilities to create, modify, read, and delete arbitrary properties
`(metadata) on all Web resources, irrespective of content type.
`Most Web resources have associated descriptive information, such as its
`author, title, publisher, keywords, copyright
`content rating, etc. While
`HTML, with its META tags provides a way to embed this information within
`HTML documents, many Web resource types have no capability for storing
`
`

`

`297
`
`metadata in their data formats. For those that do, their capabilities and storage
`locations vary by content type, making them awkward to use. Properties,
`essentially name, value pairs, are useful for recording bibliographic information,
`which can later be used in searches on property values, a capability currently
`being developed by the DA V Searching and Locating (DASL) working group
`within the IETF (DASL, 1999).
`Properties can be viewed as an assertion about a resource. For example, an
`author property asserts that the author of the resource is given in the value of the
`In a distributed system, the issue of consistency maintenance for
`property.
`properties is important-if a new author starts editing a resource, the author
`property must be updated, or it will be inconsistent. A Web server can
`automatically maintain the consistency of property values that it can compute,
`such as a property that records the length of the resource. Other properties, such
`as copyright status, can only be maintained by the client. WEBDA V terms
`properties whose syntax and semantics are enforced by the server as "live
`properties", and properties which are stored without processing, and without
`automatic consistency maintenance, as "dead properties." This leads to the
`requirement that a Web authoring protocol must support both live and dead
`properties.
`
`Support for content-type independent links
`
`As Web resources have a wide variety of relationships between them, and since
`existing Web links are unidirectional, and are supported by only a few content
`types, a Web authoring protocol must provide operations to create, modify, read,
`and delete typed links (relationships) between Web resources of any content type.
`Links can be used to capture a wide variety of relationships, such as the print
`ordering of a set of HTML documents, or related documents such as a table of
`contents, an index, or a glossary.
`
`Retrieval of unprocessed source for editing
`
`When a Web resource is retrieved using HTTP, the transmitted octets (known as
`the response entity body) are a representation of the state of the resource, and
`there is no guarantee that the actual state of the resource is being returned. Many
`Web resources exploit this, providing a representation that differs greatly from the
`underlying state of the resource. Examples include HTML with server-side-
`include directives and active server pages, which are both processed by the server
`before creating the response entity body, as well as CGI scripts, where the
`response entity body typically has no correlation with the persistent state of the
`resource, the code of the CGI script itself. Since HTTP GET always returns a
`response entity body after the server has performed its processing, a Web
`authoring protocol must provide support to retrieve an authoring-suitable
`
`

`

`298
`
`representation of the source of a Web resource.
`
`Namespace manipulation
`
`Since resources may need to be copied, or moved as a Web site evolves, a Web
`authoring protocol must provide support for copying and moving Web resources.
`There are ramifications beyond mere renaming-the behavior of a server's
`namespace may not be uniform, and policies such as freedom from automatic
`download by robot, or different cache expiration dates may vary across the
`namespace. This requirement also follows from our user metaphor of saving to a
`Web site just like any other filesystem, since most "Save As" dialog boxes
`provide the ability to list directories and manipulate names.
`The key insight is that focusing on facilities for authoring a single resource is
`insufficient. Web resources exist within a space of URL names, and a Web
`authoring protocol needs to provide support for manipulating this environment.
`
`Support for collections
`
`A Web authoring protocol must provide support for creating and deleting a
`collection, adding and removing members tolJrom a collection, and for listing the
`members of a collection.
`Collections are resources which act as containers of other resources, including
`other collections. They provide an abstraction that can group resources, and thus
`reduce the burden of authoring within a large corpus of documents. Collections
`are also used for navigation within large document spaces, as evidenced by the
`ubiquitous file navigation windows within the "Save As" and "Open" dialog
`boxes of current tools. Web authoring protocols need to support this navigation
`style. With DASL, collections will support navigation-by-query as well.
`
`The WebDA V protocol
`
`This section describes in detail the major features of the WEBDA V protocol-
`properties, locking, and namespace management-that were designed to satisfy
`the Web collaborative authoring requirements given in the previous section.
`
`Properties
`
`WEBDA V properties are name, value pairs. A property name is a Uniform
`Resource Identifier (URI), as defined in Berners-Lee et al. (1998). Property
`values are expressed as XML elements. Two methods are provided to manipulate
`properties, PROPFIND and PROPPATCH.
`
`

`

`299
`
`The PROPFIND method is used to retrieve properties, and supports three
`operations: retrieve all property names and values, retrieve selected names and
`values, or retrieve only the property names. When applied to a collection resource
`PROPFIND can be instructed to act recursively against the collection resource and
`its members. By recursively we mean that if any of the members of the collection
`are themselves collections then PROPFIND will be executed against the members of
`the sub-collections, and so on. Note that even when used recursively, only a
`single request is sent, and only a single response, with property information for all
`affected resources, is returned.
`The PROPPATCH method can set or remove multiple properties on a resource in
`an atomic operation. That is, all the set and remove commands in the PROPPATCH
`will either be successfully applied in the order submitted, or none will. To support
`dead properties, WEBDA V servers are capable of supporting arbitrary properties,
`as client-maintained "dead" values. Like PROPFIND, PROPPATCH can also be
`applied recursively against collection resources.
`For example, DAV:source is one normative property defined in the WEBDA V
`protocol. If present, it provides a link from a resource to a URL where a
`representation suitable for authoring can be retrieved.
`
`Design rationale for properties
`
`Several different designs were considered for properties. The first design used
`typed links: a set of URLs that expressed a relationship between two or more
`resources. To express the relationship "is-author-of', a link would be defined
`from the document being authored to a separate resource that contained the name
`of the author. Though powerful, this link-based design was rejected for
`performance reasons, since it resulted in many network requests, and because
`consistency maintenance of linked metadata is difficult.
`The approach which was finally adopted flowed from the notion of allowing
`"links" to record metadata strings directly. Thus small properties could be
`recorded directly inside of the property's value, while large values could be
`accessed indirectly through a URL. This design better suits the preponderance of
`metadata which consists of "small" data items, such as an author's name.
`The PROPFIND method allows multiple property values to be retrieved at once,
`thus satisfying performance requirements. XML is used for the default property
`syntax as a simple, yet structured format for property values. In addition,
`WEBDAV's additional rule that any XML elements not understood must be
`ignored allows property values to be extended while retaining backward
`compatibility. XML also allows properties to contain arbitrary data with less
`complexity than the dual method design.
`The ultimate argument in favor of this design for PROPPATCH is the
`interdependence of property values and resource state. For example, if properties
`
`

`

`300
`
`A & B have mutually dependent values and a client crashes between updating A
`and B, the resource would be left in an inconsistent state. This led to the inclusion
`of both set and delete commands in the PROPPATCH method, in conjunction with
`the atomicity requirement.
`URIs are used to name WEBDA V properties, because many different groups
`and applications will create new properties. URIs form a controlled namespace
`that provides support for both centralized and decentralized extensions yet
`guarantees uniqueness. Registering a new URI scheme gains the benefits of a
`centrally controlled namespace, while using URLs allows any organization with a
`domain name to create new property names.
`
`Locking
`
`Concurrency control within the WEBDA V protocol is provided by write locks.
`The LOCK method supports two types of locks: "exclusive write locks" and
`"shared write locks". Since any kind of principal-human or Web robot-could
`write to a Web resource, a write lock prevents any principal other than the lock
`owner, from writing to a locked resource. An exclusive write lock prevents all
`principals other than the single lock owner from writing to the resource, while a
`shared write lock can be owned simultaneously by several users. This
`terminology differs from the typical database use, where a shared lock is typically
`taken out prior to reading a database cell.
`The lock compatibility table for write locks is given in Table I.
`
`SHARED LOCK
`EXCLUSIVE LOCK
`REQUEST
`CURRENT LOCK STATE REQUEST
`Granted
`None
`Granted
`Not Granted
`Shared Lock
`Granted
`Exclusive Lock
`Not Granted
`Not Granted
`Table I: Lock compatibility table. The current lock state of the resource is given
`in the leftmost column, and lock requests are listed in the first row. The
`intersection of row and column gives the results of a lock request, where
`"granted" means the lock was granted, and "not granted" means the lock was not
`granted.
`
`Principals are identified using Digest Authentication, an extension to HTTP
`specified in Franks et al. (1997). This scheme, which uses multiple one-way
`hashes to encrypt a usemame, password pair, is substantially better than
`authentication schemes in existing remote authoring tools. For example, MESSIE
`(Sasse et al., 1993) only transmits an unencrypted usemame before granting write
`access to a repository. HYPER-G, whose Client-Server Protocol is described in
`
`

`

`301
`