You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
987 lines
40 KiB
987 lines
40 KiB
<!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ö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&selection=WWW-HTML%2C+1994-5&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ö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 &
|
|
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>
|