NOTE-ioh-arch 39.5 KB

Raw Blame History Permalink

<!DOCTYPE report public "-//W3C//DTD Report 1997-05-18//EN"
                        "../XML/9705/report.dtd">
<report>
  <head>
    <title>An Evaluation of the World Wide Web with respect to
    Engelbart's Requirements</title>
    <!-- link rel=stylesheet href="test.css" -->
  </head>

  <titlepage>
  <H1>An Evaluation of the World Wide Web with respect to Engelbart's
  Requirements</H1>

  <ADDRESS>
    <author><A HREF="../People/Connolly/">Daniel W. Connolly</A>
    <affiliation><A HREF="../../"><br>W3C</A><A
    HREF="http://www.lcs.mit.edu/">MIT LCS</A></></>

      <date><h3>$Date: 2002/08/13 22:52:26 $</h3></>
  </ADDRESS>

  <abstract>
      <status><h2>Status of This Document</h2>

	<p>This document is informational only. It does not specify
	any new specifications or protocols. The editor is working
	towards makin this document a <formal-term><a
	href="../TR/#NOTE">W3C Note</a></>.

	<p>This is based on <a href="../Collaboration/ECommerceEval">an Oct '95 conference paper</a>.</p>

      </status>
      <H3>Abstract</H3>

    <P>The architecture and implementation of the World Wide Web are
    evaluated with respect to Douglas Engelbart's requirements for an
    open hyperdocument system.  Engelbart's requirements are derived
    from experience in using computer-supported collaborative work
    (CSCW) to support large scale electronic commerce.

    <keywords><H3>Keywords</H3><A
    HREF="http://www.cs.indiana.edu/cstr/search?hypertext+system">Hypertext
    Systems</A> <A HREF="../DesignIssues/">Web Design</A>
    </keywords>
  </abstract>
  </titlepage>
  <contents></>
  <sect><H2>Introduction</H2>

    <P>The World Wide Web is targeted at collaborative work: research,
    development, marketing, advertising, negotiation, sales, and
    support, if not more. in this way. It borrows many design
    principles from the research in computer supported collaborative
    work (CSCW), which showed how effective hypermedia systems can be
    for knowledge capture, knowledge exchange, and collaboration in
    general.

    <P>In comparison to even the early hypertext research systems, the
    Web is fairly simple and somewhat limited. And yet it is extremely
    widely deployed and exploited. Is the Web technology ultimately
    limited? Is it a passing phenomenon, or is it a viable long-term
    platform for collaborative work and electronic commerce?

    <P>In <bibref><a href="#Eng90">[Eng90]</a></>, Douglas Engelbart
    condensed the results of many years of research in computer
    supported collaborative work into twelve requirements<bibref><A
    HREF="#ENG90">[ENG90]</A></>. This report evaluates the Web with
    respect to each of the requirements: has it been met? If not, can
    it? What are the obstacles, and what are the most promising
    developments in each area?
  </sect>

  <sect><H2>Essential Elements of an Open Hyperdocument System</H2>

    <P>Engelbart's research was directed at large scale knowledge
    work; for example, in the aircraft industry, the interactions
    between a major manufacturer and its contractors, subcontractors,
    and so on. Research and experimentation led to the following
    requirements:
    <OL>
      <LI><xref><A HREF="#mixdoc">Mixed Object Documents</A></>
      <LI><xref><A HREF="#structdoc">Explicitly Structured
      Documents</A></> <LI><xref><A HREF="#viewcontrol">View Control
      of Object's Form, Sequence, and Content</A></> <LI><xref><A
      HREF="#hyperdoc">The Basic
      <q><c>"</>Hyperdocument<c>"</></q></A></> <LI><xref><A
      HREF="#backlink">Hyperdocument <q><c>"</>Back-Link<c>"</></q>
      Capability</A></> <LI><xref><A HREF="#library-system">The
      Hyperdocument <q><c>"</>Library System<c>"</></q></A></>
      <LI><xref><A HREF="#hypermail">Hyperdocument Mail</A></>
      <LI><xref><A HREF="#digsig">Personal Signature Encryption</A></>
      <LI><xref><A HREF="#access-control">Access Control</A></>
      <LI><xref><A HREF="#human-addr">Link Addresses That Are Readable
      and Interpretable by Humans</A></> <LI><xref><A
      HREF="#alladdr">Every Object Addressable</A></> <LI><xref><A
      HREF="#printlink">Hard-Copy Print Options to Show Address of
      Objects and Address Specification of Links</A></>
    </OL>
  </sect>
  <sect>
    <H2>Overview of Web Architecture</H2>

    <P>In order to evaluate the Web with respect to Engelbart's
    requirements, some background on the architecture is essential.

    <P>The Web is a hypermedia distributed information system. A
    distributed information system allows users to access (read,
    search, navigate) documents from a wide variety of computers
    connected via a network. A hypertext system is one where the
    documents have links in and between each other, so that readers
    are not constrained to a sequential reading order. Finally, a
    hypermedia system is one that integrates images, sounds, video,
    and other media with text in documents.

    <P>The Web incorporates a wide variety of information sources on
    the Internet into a coherent information system. The user
    experience on the Web is:

    <OL>
      <LI>An initial document is presented to the user, consisting of
      text, graphics, sounds, animation, etc.

      <LI>The user can choose one of the links in the document and
      request to visit the document on the other end of the link. The
      link specifies the address of another document.

      <LI>The system retrieves the document at that address and
      presents it to the user, and the process repeats.
    </OL>

    <subsects>
      <subsect><H3>Protocols and Addressing Schemes</H3>

	<P>A URI, or Uniform Resource Identifier, is a name or address
	for an object in the Web<bibref><A
	HREF="#URI">[URI]</A></>. For example:

	<PRE>
http://www.w3.org/ ftp://ds.internic.net/rfc/rfc822.txt
	</PRE>

	<P>Each URI begins with <TT><VAR>scheme</VAR>:</TT>, where
	<VAR>scheme</VAR> refers to an addressing or naming
	scheme. For example, URIs beginning with <TT>http: </TT>refer
	to objects accessible via the HTTP protocol; <TT>ftp:</TT>
	refers to FTP objects, and so on. New schemes can be added
	over time.

	<P>There are a number of information retrieval protocols on
	the Internet: FTP, gopher, WAIS, etc. In the Web user
	experience, they behave similarly: a server makes a collection
	of documents available. A client contacts a server and makes a
	request to access one or more of the documents by giving a
	command telling what sort of access (read, write, etc.) and
	some parameters that indicate which is the relevant document
	(s). Finally, the server fulfills the request by, for example,
	transmitting the relevant document to the client.

	<P>HTTP is a protocol designed specifically for the
	Web<bibref><A HREF="#HTTP">[HTTP]</A></>. It is an extensible
	protocol with support for the widely used features of existing
	protocols, such as file transfer and index searching, plus
	support for some novel features such as redirection and format
	negotiation.

      </subsect>

      <subsect><H3>Data Formats</H3>

	<P>There is no one data format for all Web documents<emdash>
	-- </>each document may have its own format. In fact, it may
	be available in many formats.

	<P>Each data format has a name, or an Internet Media
	Type. Internet Media Types, aka content types, are part of
	MIME<bibref><A HREF="#MIME">[MIME]</A></>, a collection of
	enhancements to Internet mail to accomodate rich media. Most
	Internet Media Types are just standardized names for existing
	data formats; for example, <TT>text/plain</TT> for normal
	ASCII text; <TT>image/gif</TT> for images in GIF format, etc.

	<P>The MIME standard also introduces some new data
	formats. The <TT>multipart/mixed</TT> is a <DFN>compound</DFN>
	data format<emdash> -- </>it allows several pieces of media to
	be combined into one, for transmission via email, storage in a
	file, etc.

	<P>
	  Hypertext Markup Language (HTML) is a data format designed
	  specifically for the Web. It combines the features of a
	  typical structured markup language (paragraphs, titles,
	  lists) with hypertext linking features.
	<P>
	  HTML is an application of SGML, the Standard Generalized
	  Markup Language<bibref><A HREF="#SGML">[SGML]</A></>. SGML
	  is a technology for specifying structured document
	  types. HTML is one such document type, but there are many
	  others<emdash> -- </>as many as anyone cares to dream
	  up. TEI, DocBook, and Pinnacles are just a few of the types
	  of SGML documents used in the web<bibref><A
	  HREF="#NCSASGML">[NCSASGML]</A></>.
      </subsect>
    </subsects>
  </sect>
  <sect>
    <H2>Evaluating the World Wide Web</H2>
    <P>
      This evaluation measures the World Wide Web against each of
      Engelbart's requirements, discussing strengths, weaknesses, and
      promising developments.</>
    <subsects>
      <subsect>
	<H3><A NAME="mixdoc"><num>1. </>Mixed Object
	Documents</A></H3>
	<BLOCKQUOTE>
	  <p>to provide for an arbitrary mix of text, diagrams,
	  equations, tables, raster-scan images (single frames, or
	  even live video), spread sheets, recorded sound,
	  etc.<emdash> -- </>all bundled within a common
	  <q><c>"</>envelope<c>"</></q> to be stored, transmitted,
	  read (played) and printed as a coherent entity called a
	  <q><c>"</>document.<c>"</></q>
	</BLOCKQUOTE>
	<P>
	  The first Web documents contained only text, but support for
	  icons and images was added to NCSA Mosaic in 1993. Since
	  then, Web pages with mixed text and graphics have been the
	  rule, and sound and video are not uncommon. As a recent
	  development, tables are widely deployed. Support for
	  equations is still essentially in development, and diagrams
	  are generally limited to rasterized snapshots.
	<P>
	  Exchange of spreadsheets and other rich data sets associated
	  with proprietary software packages is supported to some
	  extent, but its use is generally limited to small
	  communities of interest who agree to use the packages.
	<P>
	  This demonstrates that at least to some extent, the
	  requirement for mixed object documents is met. But it is not
	  met completely: the tools for composing mixed object
	  documents are primitive, and many features of a
	  comprehensive compound document architecture are lacking.</>
	<subsubsects>
	  <subsubsect>
	    <H4>
	      Authoring Tools
	    </H4>
	    <P>
	      The intent of the original design of the web was that
	      documents would be composed in direct-manipulation
	      fashion from a rich set of media objects.  The initial
	      prototype was done on the NeXTStep platform, which
	      allows drag-and-drop editing of rich text documents
	      including raster images, encapsulated postscript images,
	      sounds, diagrams, etc. The NeXTStep platform includes an
	      architecture and a set of development tools for adding
	      new object types to the mix available on the desktop.

	    <P>System such as <bibref><a
	    href="#hyperg">[Hyper-G]</A></> provide many of these
	    features, and recently products such as <bibref><A
	    HREF="#navisoft">[NaviPress]</A></> and <bibref><A
	    HREF="#frontpage">[FrontPage]</A></> beginning to provide
	    these features to the web user base at large.

	  </subsubsect>
	  <subsubsect>
	    <H4>
	      Compound Document Architecture
	    </H4>
	    <P>
	      The two technologies used to create compound documents
	      on the web are URIs and MIME. Objects can be linked
	      together by using their addresses. For example, the HTML
	      A, IMG, FORM, and LINK elements specify URIs of linked
	      objects.  Links are typed to indicate various
	      relationships between objects such as parent/child,
	      precedes/succeeds, supports/refutes, etc. The MIME
	      multipart facility allows several pieces of content to
	      be combined into one entity.  Support for typed links
	      and multipart data is deployed only to a limited extent.
	    <P>
	      The combination of URIs and MIME supports the entire
	      existing web information space. Still, compared with
	      compound document architectures such as OpenDoc, OLE,
	      Fresco, LINCKS<bibref><A HREF="#LINCKS">[LINCKS]</A></>,
	      or HyTime, many facilities are lacking.
	    <P>
	      Facilities for diagrams, equations, screen real-estate
	      arbitration, event management, versioning, transactions,
	      link indirection, and aggregation have been developed
	      for various web applications, but there are no standard
	      facilities. Standards for such facilities might result
	      in a critical mass of shared of technology that would
	      make feasible classes of applications that were
	      previously too costly.
	  </subsubsect>
	</subsubsects>
      </subsect>
      <subsect>
	<H3><A NAME="structdoc"><num>2. </>Explicitly Structured
	Documents</A></H3>

	<BLOCKQUOTE>
	  <p>where the objects comprising a document are arranged in
	  an explicit hierarchical structure, and compound-object
	  substructures may be explicitly addressed for access or
	  manipulation of the structural relationships.
	</BLOCKQUOTE>
	<P>
	  The Hypertext Markup Language used to represent most web
	  documents is a structured document format. Elements of HTML
	  documents are explicitly tagged, and structure can be
	  inferred from the tags. Not all substructures may be
	  explicitly addressed<emdash> -- </>only anchor elements and
	  embedded objects.
	<P>
	  Fragment identifiers in URIs allow compound-object
	  substructures to be explicitly addressed.
	<P>
	  Other hierarchical structures are possible, but not yet
	  supported. One facility that is notably lacking from Web
	  implementations is transclusion<emdash> -- </>the ability to
	  include one text object inside another by reference. For
	  example, to include an excerpt of one document inside
	  another, or to build a document out of section and
	  subsection objects.
	<P>
	  Even if transclusion were supported, compound text documents
	  would probably be prohibitively expensive: the overhead for
	  a transaction in the current version of the HTTP protocol is
	  very high; hence the protocol is inefficient for retrieving
	  a number of small objects in succession. This inefficiency
	  is being addressed in efforts to revise the protocol.
	<P>
	  Because HTML is essential to interoperability, it is
	  restricted to document structures that are universally
	  applicable. In many situations, a custom document type would
	  support more expressive collaboration. Widespread support
	  for custom SGML document types would enable such
	  collaboration.
	<P>
	  SGML is not the only structured document technology
	  available. The multipart media types support explicit
	  hierarchical structure, and support for them is being
	  deployed.
	<P>
	  The Web architecture clearly supports the requirement for
	  structured documents.  But the deployed software provides
	  limited support. The Web is predominately used in a
	  <q><c>"</>publish and browse<c>"</></q> fashion; data
	  transmitted across the Web is largely throw-away data that
	  looks good but has little structure. In order to use the Web
	  as a rich collaboration platform, much more support for
	  structured documents will be needed.
      </subsect>
      <subsect>

	<H3><A NAME="viewcontrol"><num>3. </>View Control of Object's
	Form, Sequence, and Content</A></H3>

	<BLOCKQUOTE>
	  <p>where a structured, mixed-object document may be
	  displayed in a window according to a flexible choice of
	  viewing options<emdash> -- </>especially by selective level
	  clipping (outline for viewing), but also by filtering on
	  content, by truncation or some algorithmic view that
	  provides a more useful view of structure and/or object
	  content (including new sequences or groupings of objects
	  that actually reside in other documents). Editing on
	  structure or object content from such special views would be
	  allowed whenever appropriate.
	</BLOCKQUOTE>
	<P>View control can be achieved on the Web by custom
	processing by the information provider. A number of views can
	be provided, and the consumer can express their choice via
	links or HTML forms. For example, gateways to database query
	systems and fulltext search systems are commonplace. Another
	technique is to provide multiple views of an SGML document
	repository<bibref><A HREF="#dynatext">[dynatext, </A></>
	<bibref><A HREF="#I4I">I4I]</A></>.

	<P>Another approach to view control is client-side processing:
	after the document is transmitted, the reader's software could
	filter, sort, or truncate the data. About the only such
	control in wide deployment is the ability to turn off embedded
	images. Outline views with folding have been proposed
	<bibref><A HREF="#FOLD">[FOLD]</A></>, but the cost of
	transmitting text that isn't displayed has presented a
	barrier.
	<P>
	  Stylesheets are a mechanism for presenting the same data in
	  different forms, using fonts, colors, and space to give
	  visual structure. Support for stylesheets is an important
	  ongoing development.
	<P>
	  But in some systems<bibref><A HREF="#LINCKS">[LINCKS, </A>
	  <A HREF="#dynatext">dynatext]</A></>, stylesheets are much
	  more than that: they control form, sequence, and content as
	  Engelbart described. For example, in LINCKS, the same
	  document can be presented and edited in abstract form,
	  outline form, or full form depending on which stylesheet
	  (generic presentation descriptor, in their jargon) is in
	  effect.
	<P>
	  At the extreme end of the spectrum, stylesheets give way to
	  arbitrary programs that display data and interact with the
	  reader. In a distributed system, running arbitrary programs
	  can have dangerous consequences. But advances such as
	  Safe-Tcl and Java make this technique of <q><c>"</>active
	  objects<c>"</></q> feasible.
	<P>
	  It's clear that the Web architecture supports custom view
	  control. It remains to be seen whether some view control
	  mechanisms are sufficiently valuable to be standardized.
      </subsect>
      <subsect>
	<H3><A NAME="hyperdoc"><num>4. </>The Basic
	<q><c>"</>Hyperdocument<c>"</></q></A>
	</H3>
	<BLOCKQUOTE>
	  <p>where embedded objects called <q><c>"</>links<c>"</></q>
	  can point to any arbitrary object within the document, or
	  within another document in a specified domain of
	  documents<emdash> -- </>and the link can be actuated by a
	  user or an automatic process to <q><c>"</>go see what is at
	  the other end,<c>"</></q> or <q><c>"</>bring the other-end
	  object to this location,<c>"</></q> or <q><c>"</>execute the
	  process identified a the other end.<c>"</></q> (These
	  executable processes may control peripheral devices such as
	  CD ROM, video-disk players, etc.)
	</BLOCKQUOTE>
	<P>
	  This requirement is clearly met. The hyperdocument as
	  described above is the epitome of the Web page.
	<P>
	  The only exception is that Engelbart refers to links as
	  <q><c>"</>special objects,<c>"</></q> whereas in the Web,
	  links are not addressable <q><c>"</>first-class<c>"</></q>
	  objects<emdash> -- </>not in implementations, and not in the
	  architecture.
      </subsect>
      <subsect>
	<H3><A NAME="backlink"><num>5. </>Hyperdocument
	<q><c>"</>Back-Link<c>"</></q> Capability</A>
	</H3>
	<BLOCKQUOTE>
	  <p>when reading a hyperdocument online, a worker can utilize
	  information about links from other objects within this or
	  other hyperdocuments that point to this
	  hyperdocument<emdash> -- </>or to designated objects or
	  passages of interest in this hyperdocument.
	</BLOCKQUOTE>
	<P>
	  The design of the Web trades link consistency guarantees for
	  global scalability.  Links are one way , and the reverse
	  link is not guaranteed to exist.
	<P>
	  Aside from the intractability of maintaining global link
	  consistency, another barrier to a distributed back-link
	  service is privacy. Some links are sensitive, and their
	  owners do not want them easily discovered.
	<P>
	  These barriers do not, however, prevent Web users from
	  utilizing back-link information. Some Web server tools
	  <bibref><A HREF="#frontpage">[FrontPage]</A></>) maintain
	  back-link information for the local site. And the HTTP
	  protocol includes a mechanism<emdash> -- </>the
	  <TT>Referer:</TT> field <emdash> -- </>that allows
	  information providers to gather back-link information for
	  their site.
	<P>
	  Finally, there are search services that traverse the web
	  building full-text search indexes. Some <bibref><A
	  HREF="#altavista">[Altavista]</A></> take advantage of the
	  links they encounter to offer back-link services.
      </subsect>
      <subsect>
	<H3><A name="library-system"><num>6. </>The Hyperdocument
	<q><c>"</>Library System<c>"</></q></A></H3>

	<BLOCKQUOTE>
	  <p>where hyperdocuments can be submitted to a library-like
	  service that catalogs them and guarantees access when
	  referenced by its catalog number, or <q><c>"</>jumped
	  to<c>"</></q> with an appropriate link. Links within newly
	  submitted hyperdocuments can cite any passages within any of
	  the prior documents, and the back-link service lets the
	  online reader of a document detect and <q><c>"</>go
	  examine<c>"</></q> any passage of a subsequent document that
	  has a link citing that passage.
	</BLOCKQUOTE>

	<P>There are no guarantees of access on the web today. A few
	commercial web service providers <bibref><A
	HREF="#navipress">[NaviService]</A></> guarantee server
	availability on a 24x7 basis, but this doesn't guarantee
	access to the entire global user base<emdash> -- </>any
	network interruption between the reader and the provider can
	prevent access.

	<P>
	  In a distributed system, absolute guarantees are
	  impossible. But reliability can be made arbitrarily good by
	  investing in redundancy. A number of strategies for caching
	  and replication (including <bibref><A
	  HREF="#harvest">Harvest</A></>) are being explored,
	  standardized, and deployed.
	<P>
	  Catalog numbering systems have not matured either. This is
	  known as <q><c>"</>the URN problem.<c>"</></q> A number of
	  promising proposals have been made <bibref><A
	  HREF="#PATH">[PATH, </A><A HREF="#STANF">STANF]</A></>, but
	  none is widely deployed.

	<P>Digital Libraries is an active field of research. ARPA is
	funding research, and the Online Computer Library Center is
	conducting experiments.

      </subsect>
      <subsect>
	<H3><A NAME="hypermail"><num>7. </>Hyperdocument Mail</A></H3>
	<BLOCKQUOTE>
	  <p>where an integrated, general-purpose mail service enables
	  a hyperdocument of any size to be mailed. Any embedded links
	  are also faithfully transmitted<emdash> -- </>and any
	  recipient can then follow those links to their designated
	  targets in other mail items, in common-access files, or in
	  <q><c>"</>library<c>"</></q> items.
	</BLOCKQUOTE>
	<P>
	  Internet Mail is possibly the world's most widely deployed
	  information system.  MIME, the Multipurpose Internet Mail
	  Extensions, standardizes facilities for attachments and
	  compound documents, among other things.
	<P>
	  Though nearly every new mail system supports MIME, the
	  installed base of pre-MIME mail systems is still significant
	  <emdash> -- </>a majority by many estimates.
	<P>
	  User interfaces that integrate email (and USENET news) into
	  the Web user experience are anticipated, but not deployed.
      </subsect>
      <subsect>
	<H3><A NAME="digsig"><num>8. </>Personal Signature
	Encryption</A></H3>
	<BLOCKQUOTE>
	  <p>where a user can affix his personal signature to a
	  document, or a specified segment within the document, using
	  the private signature key. Users can verify that the
	  signature is authentic and that no bit of the signed
	  document or document segment has been altered since it was
	  signed.
	</BLOCKQUOTE>
	<P>
	  There are a number of digital signature standards, but none
	  has been globally adopted and deployed on the web.
	<P>
	  One barrier is patent licensing. A critical feature of web
	  technology that led to its rapid deployment was its
	  royalty-free copyright status. Patents on public-key
	  cryptography prevent digital signature technology from being
	  deployed without license negotiations.
	<P>
	  Another barrier is export control
	  legislation. Implementations of cryptographic techniques
	  such as encryption are considered munitions by many
	  governments, and there are strict controls on the export of
	  such technologies.
	<P>
	  But the largest barrier is the social and educational
	  one. Digital signature techniques will have to be tested in
	  production use, and users will have to be educated about the
	  related issues before commerce can depend on this
	  technology.
      </subsect>
      <subsect>
	<H3><A NAME="access-control"><num>9. </>Access
	Control</A></H3>
	<BLOCKQUOTE>
	  <p>Hyperdocuments in personal, group, and library files can
	  have access restrictions down to the object level.
	</BLOCKQUOTE>
	<P>
	  The distributed nature of the Web allows information
	  providers to implement any access control policy they
	  choose, down to the object level.
	<P>
	  Minimal support for username/password authentication is
	  widely deployed.  This allows information providers to
	  implement access control based on users and groups of
	  users. But this basic facility is not robust in the face of
	  concerted attack.
	<P>
	  A number of mechanisms for strong authentication and
	  confidentiality, as well as billing and payment are being
	  standardized. A complete discussion of these mechanisms is
	  beyond the scope of this document.
      </subsect>
      <subsect>
	<H3><A NAME="human-addr"><num>10. </>Link Addresses That Are
	Readable and Interpretable by Humans</A></H3>
	<BLOCKQUOTE>
	  <p>one of the <q><c>"</>viewing options<c>"</></q> for
	  displaying/printing a link object should provide a
	  human-readable description of the <q><c>"</>address
	  path<c>"</></q> leading to the cited object; AND, that the
	  human must be able to read the path description, interpret
	  it, and follow it (find the destination <q><c>"</>by
	  hand<c>"</></q> so to speak).
	</BLOCKQUOTE>
	<P>
	  Document addresses in the web are designed so that they can
	  be transcribed<emdash> -- </>written on envelopes, recited
	  over the phone, etc. Each URI scheme has an associated
	  public specification of how to interpret and follow its path
	  description.
	<P>
	  By and large, URIs are sensible to those familiar with the
	  conventions<emdash> -- </><TT>http://www.ford.com</TT> is
	  the address of Ford Motor Company, for example.

	<P>But portions of URIs are allowed to be opaque by
	design<emdash> -- </>they may be pointers into an index,
	checksums, dates, etc.

      </subsect>
      <subsect>
	<H3><A NAME="alladdr"><num>11. </>Every Object
	Addressable</A></H3>
	<BLOCKQUOTE>
	  <p>in principal, every object that someone might validly
	  want/need to cite should have an unambiguous address
	  (capable of being portrayed in a manner as to be human
	  readable and interpretable). (E.g. not acceptable to be
	  unable to link to an object within a
	  <q><c>"</>frame<c>"</></q> or <q><c>"</>card.<c>"</></q>)
	</BLOCKQUOTE>
	<P>
	  Every object on the web is addressable. But not every
	  substructure within objects that someone might need to cite
	  has a standard addressing mechanism.  For example,
	  individual pages in a postscript document, lines in a text
	  file, pixels in an image.
	<P>
	  These structures are, in principle, addressable. Only a
	  standard syntax for URI fragment identifiers to address them
	  is lacking.
	<P>
	  In HTML documents, elements can be named and addressed. But
	  there is no mechanism to address unnamed elements. For
	  parties that do not have write access to a document, this
	  presents a problem.
	<P>
	  One solution would be to allow elements to be addressed by
	  their structural position. There are a number of standard
	  technologies for addressing elements of SGML documents (and
	  hence HTML documents): TEI pointers, HyTime location
	  ladders, and DSSSL queries. Any of these could be
	  incorporated into web software.
	<P>
	  Another possibility is to address strings within a document
	  by pattern matching.  One annotation system<bibref><A
	  HREF="#BRIO">[BRIO]</A></> uses patricia trees for stable
	  pointers into documents.
      </subsect>
      <subsect>
	<H3><A NAME="printlink"><num>12. </>Hard-Copy Print Options to
	Show Address of Objects and Address Specification of Links</A>
	</H3>
	<BLOCKQUOTE>
	  <p>so that, besides online workers being able to follow a
	  link-citation path (manually, or via an automatic link
	  jump), people working with associated hard copy can read and
	  interpret the link-citation, and follow the indicated path
	  to the cited object in the designated hard-copy document.
	  <P>
	    Also, suppose that a hard-copy worker wants to have a link
	    to a given object established in the online file. By
	    visual inspection of the hard copy, he should be able to
	    determine a valid address path to that object and for
	    instance hand-write an appropriate link specification for
	    later online entry, or dictate it over a phone to a
	    colleague
	</BLOCKQUOTE>
	<P>
	  Most of the installed base of web client software allows
	  users to view link address. But ironically, that option is
	  not available for printing in many cases. It would be a
	  straightforward enhancement, well within the bounds of the
	  existing architecture.
      </subsect>
    </subsects>
  </sect>
  <sect>
    <H2>Summary</H2>
    <P>
      In the following table, each row represents one of Engelbart's
      requirements.  The columns are as follows:
    <DL>
      <DT>
	Architecture Support
	<DD>
	  Is the requirement explicitly addressed in the Web
	  architecture? Does the architecture passively allow the
	  requirement to be met by applications? Or does the
	  architecture conflict with the requirement?
      <DT>
	Standard Facilities
	<DD>
	  Are there standardized facilities that meet the requirement?
	  Partially meet the requirement?
      <DT>
	Ubiquitous Facilities
	<DD>
	  Some facilities are standardized, but not required of all
	  systems, or not supported by all installations. What
	  facilities are assumed to be supported by all participants
	  in the web?
      <DT>
	Local/Proprietary Facilities
	<DD>
	  Has the requirement been met within the architecture by
	  local applications or with the use of proprietary
	  facilities?
    </DL>
    <P>
      Each cell contains an evaluation of whether the requirement is
      met (YES, NO, PASSive, or PARTial) followed by a list of
      relevant facilities. Missing facilities are marked with *.

    <TABLE>
      <caption>Evaluation</caption>
      <TR>
	<TH>Requirement</TH> <TH>Architecture Support</TH>
	<TH>Standard Facilities</TH> <TH>Ubiquitous Facilities</TH>
	<TH>Local/Proprietary Facilities</TH>
      </TR>
      <TR>
	<TD>1. Mixed Object Documents</TD> <TD>YES: format
	  negotiation, typed links</TD> <TD>PART: URI, HTML, IMG,
	  INSERT, MIME<BR> link types*</TD> <TD>PART: GIF in HTML</TD>
	<TD>YES: JPEG in HTML, Java/Safe-Tcl in HTML, OLE, OpenDoc,
	  Fresco<BR>
	  <BR>
	</TD>
      </TR>
      <TR>
	<TD>2. Explicitly Structured Documents</TD> <TD>YES:
	  fragment identifiers</TD> <TD>YES: HTML, SGML, MIME</TD>
	<TD>PART: HTML</TD> <TD>YES: Panorama, OLE, LINCKS</TD>
      </TR>
      <TR>
	<TD>3. View Control of Object's Form, Sequence, and
	  Content</TD> <TD>PASS</TD> <TD>PART: HTTP, CGI</TD>
	<TD>NO</TD> <TD>YES: DynaWeb, Java/Safe-Tcl, Style
	  Sheets</TD>
      </TR>
      <TR>
	<TD>4. The Basic <q><c>"</>Hyperdocument<c>"</></q></TD>
	<TD>YES</TD> <TD>YES: URI, HTML</TD> <TD>YES: URI, HTML</TD>
	<TD></TD>
      </TR>
      <TR>
	<TD>5. Hyperdocument <q><c>"</>Back-Link<c>"</></q>
	  Capability</TD> <TD>PASS</TD> <TD>PART: Referer</TD>
	<TD>NO</TD> <TD>YES: local link map, back-link service</TD>
      </TR>
      <TR>
	<TD>6. The Hyperdocument <q><c>"</>Library
	    System<c>"</></q></TD> <TD>PASS</TD> <TD>NO</TD> <TD>NO</TD>
	<TD>NO</TD>
      </TR>
      <TR>
	<TD>7. Hyperdocument Mail</TD> <TD>PASS</TD> <TD>YES:
	  MIME</TD> <TD>YES: MIME</TD> <TD></TD>
      </TR>
      <TR>
	<TD>8. Personal Signature Encryption</TD> <TD>PASS</TD>
	<TD>NO</TD> <TD>NO</TD> <TD>YES: S-HTTP, PEM, S/MIME, PGP,
	  PKCS-7</TD>
      </TR>
      <TR>
	<TD>9. Access Control</TD> <TD>YES</TD> <TD>PART: Basic
	  auth</TD> <TD>PART: Basic Auth</TD> <TD>YES: MD5, SSL,<BR>
	  S-HTTP, PGP, smart cards, etc.</TD>
      </TR>
      <TR>
	<TD>10. Link Addresses That Are Readable and Interpretable
	  by Humans</TD> <TD>PART: URI</TD> <TD>PART: URI</TD>
	<TD>PART: URI</TD> <TD></TD>
      </TR>
      <TR>
	<TD>11. Every Object Addressable</TD> <TD>objects: YES
	  substructures: PASS</TD> <TD>PART: URI</TD> <TD>PART:
	  URI</TD> <TD></TD>
      </TR>
      <TR>
	<TD>12. Hard-Copy Print Options to Show Address of Objects
	  and Address Specification of Links</TD> <TD>PASS</TD>
	<TD>NO</TD> <TD>NO</TD> <TD>YES: HTML2LaTeX</TD>
      </TR>
    </TABLE>
    <P>
  </sect>
  <sect><H2>Conclusions</H2>

    <P>Support for Engelbart's requirements is far from
    ubiquitous. But the architecture in no way prevents them from
    being realized, and the quantity of resources integrated into the
    system provides ample motivation for research and development.
    <P>
      In each area where facilities to meet the requirement are not
      ubiquitous, a demonstration of sufficient facilities has taken
      place.
    <P>
      This gives confidence that the requirements will eventually be
      met and become infrastructure.
    <P>
      If in fact Engelbart's requirements are an effective way to
      measure the viability of a platform for electronic commerce, the
      Web is very likely to be a viable platform for some time to
      come.
  </sect>
  <sect>
    <H2>
      Acknowledgements
    </H2>
    <P>
      This paper has been in development since I met Douglas Engelbart
      and Tim Berners-Lee on the same day at Hypertext '91.
    <P>
      Since then, a number of collaborators have influenced my
      perspective on web design: Roy Fielding, Larry Masinter, Terry
      Allen, and Stu Wiebel to name a few.
    <P>
      Thanks to Jim Miller for his encouragement and review comments.

    <P>I would also like to thank Ravi Kalakota, who invited me to
    write this paper and present it at <bibref><a
    href="#austin-ecommerce">[UT95]</a>, and Keith Instone and the
    participants of the <a href="http://instone.org/keith/hrweb/ht96-call.html">HRWeb workshop</a> at Hypertext '96 in Washington D.C. </>.

  </sect>
  <references><H2>References</H2>
    <DL>
      <DT><A name=BRIO>[BRIO]</A>

	<DD><ref.inproceedings><ref.title><A
	HREF="http://www-diglib.stanford.edu/diglib/pub/reports/brio_www95.html">Beyond
	Browsing: Shared Comments, SOAPs, Trails and On-line
	Communities</A></> <ref.author>by M.  R&ouml;scheisen, C. Mogensen
	and T. Winograd</> <ref.intitle>appeared in <A
	HREF="http://www.igd.fhg.de/www95.html">Fifth International
	World Wide Web Conference</A></> <ref.pub.addr>Darmstadt</>,
	<ref.date num=1995>1995</>. See also <A
	HREF="http://www-diglib.stanford.edu/diglib/pub/reports/COMMENTOR">ComMentor
	Documentation</A>.[html document, 88k] added Feb. 21, 1995</>

      <DT><A name=ENG90>[ENG90]</A>

	<DD><ref.inproceedings><ref.title><A
	HREF="http://www.bootstrap.org/augment/AUGMENT/132082.html"> Knowledge-Domain
	Interoperability and an Open Hyperdocument System</A></>
	<ref.author>Douglas C.  Engelbart</> <ref.intitle>Proceedings
	of the Conference on Computer-Supported Collaborative Work</>,
	<ref.pub.addr>Los Angeles, CA</> <ref.date num="19901007">Oct
	7-10,</> <ref.pages>pp. 143-156.</> (AUGMENT, 132082).</>

      <DT><A name=FOLD>[FOLD]</A>

	<DD><ref.email><ref.title>Proposal<emdash> -- </>Foldable
	Anchor Inclusion</> ,<ref.author><a
	href="mailto:torrance@ai.mit.edu">Mark Torrance</a></> message
	to <ref.pub.addr>www-talk@w3.org</>, <ref.date
	num="19940727">Tue, 26 Jul 94 13:40:42 EDT</>. See: <A
	HREF="http://www.eit.com/cgi-bin/wwwwais?keywords=Outline+Fold&amp;selection=WWW-HTML%2C+1994-5&amp;maxhits=40">archives</A>.</>


      <DT><A name=HTML>[HTML]</A>

	<DD><ref.report><ref.title>HyperText Markup Language
	Specification<emdash> -- </>2.0</>, <ref.institution><A
	HREF="http://www.ietf.org/">IETF</A></> <ref.num><A
	HREF="ftp://ds.internic.net/rfc/rfc1866.txt">RFC 1866</A></>
	<ref.author>T. Berners-Lee and D. Connolly</>, <ref.date
	num="199511">November 1995</>.</>

      <DT><A name=HTTP>[HTTP]</A>

	<DD><ref.report><A
	HREF="ftp://ds.internic.net/internet-drafts/draft-ietf-http-v10-spec-00.ps">Hypertext
	Transfer Protocol - HTTP/1.0</A>. T. Berners-Lee,
	R. T. Fielding, and H. Frystyk Nielsen. Work in Progress, MIT,
	UC Irvine, CERN, March 1995.</>

      <DT><A name=LINCKS>[LINCKS]</A>

	<DD><ref.report>LINCKS<emdash> -- </>a platform for
	cooperative information systems, P. Lambrix, M.  Sj&ouml;lin, and
	L. Pagdham, unpublished manuscript, Department of Computer and
	Information Science, LiTH, Sweden, 1993. See: <A
	HREF="http://www.ida.liu.se/~lincks/">LINCKS Home Page</A></>

      <DT><A name=MIME>[MIME]</A>

	<DD><ref.report>MIME (Multipurpose Internet Mail Extensions)
	Part One: Mechanisms for Specifying and Describing the Format
	of Internet Message Bodies. N.  Borenstein &amp;
	N. Freed. September 1993. (Format: TXT=187424, <A
	HREF="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1521.ps">PS</A>=393670
	bytes) (Obsoletes RFC1341) (Updated by RFC1590)</>

      <DT><A name=NCSASGML>[NCSASGML]</A>

	<DD><ref.report><A
	HREF="http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/WebSGML.html">Welcome
	to SGML on the Web</A>, Lucy Ventresca, NCSA and
	SoftQuad. Work in Progress.</>

      <DT><A name=PATH>[PATH]</A>

	<DD><ref.report><A
	HREF="http://union.ncsa.uiuc.edu/~liberte/www/path.html">The
	Path URN Specification </A>, D. LaLiberte, M. Shapiro,
	Internet Draft 07/26/1995</>

      <DT><A name=STANF>[STANF]</A>

	<DD><ref.report><A
	HREF="http://www.saintjoe.edu/URI/stanf.html">table Network
	File URLs as a Mechanism for Uniform Naming </A> Terry
	Winograd. Early draft version 12/2/93</>

      <DT><A name=SGML>[SGML]</A>

	<DD><ref.report><A
	HREF="http://www.iso.ch/cate/d16387.html">ISO
	8879</A>. Information Processing<emdash> -- </>Text and Office
	Systems - Standard Generalized Markup Language (SGML),
	1986.</>

      <DT><A name=URI>[URI]</A>

	<DD><ref.report><A
	href="http://info.internet.isi.edu:80/in-notes/rfc/files/rfc1630.txt">rfc1630.txt</A>
	<emdash> -- </>Universal Resource Identifiers in WWW: A
	Unifying Syntax for the Expression of Names and Addresses of
	Objects on the Network as used in the World-Wide
	Web. T. Berners-Lee. June 1994. (Format: TXT=57601 bytes)</>

      <dt><a name=hyperg>[HyperG]</a> <dd><ref.email><a
      HREF="http://hyperg.iicm.tu-graz.ac.at/Chyperg">Hyper-G</A>@@</>


      <dt><a name=navipress>[Navipress]</a> <dd><ref.email><A
      HREF="http://www.navisoft.com/">NaviPress</A>, <a
      HREF="http://www.naviservice.com/">NaviService</A>@@</>

      <dt><a name=frontpage>[FrontPage]</a> <dd><ref.email><A
      HREF="http://www.vermeer.com/">FrontPage</A>@@</>

      <dt><a name=dynatext>[Dynatext]</a> <dd><ref.email><A
      HREF="http://www.ebt.com/">dynatext</A>@@</>

      <dt><a name="I4I">[I4I]</a> <dd><ref.email><A
      HREF="http://www.i4i.org/vision.html">I4I</A>@@</>

      <dt><a name="altavista">[AltaVista]</a> <dd><ref.email><a
      HREF="http://www.altavista.digital.com/">Altavista</A>@@</>

      <dt><a name="harvest">[Harvest]</a> <dd><ref.email><A
      HREF="http://harvest.cs.colorado.edu/">Harvest</A>@@</>

      <dt><a name="oclc">[OCLC]</a> <dd><ref.email><A
      HREF="http://www.oclc.org/">OCLC</A> research@@</>

      <dt><A name="austin-ecommerce">[UT95]</a> <dd><ref.email><a
      href="http://cism.bus.utexas.edu/ravi/ecomm.html">The First
      International Conference on Electronic Commerce</A> at the
      University of Texas at Austin, Austin, October 1995 @@</>

    </DL>
  </references>
</report>