In [Eng90], Douglas Engelbart condensed the results of many years of
research in computer supported collaborative work into twelve
requirements[ENG90]. 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?
http://www.w3.org/Architecture/NOTE-ioh-arch#LINCKS
SUMMARY
In the following table, each row represents one of Engelbart's
requirements. The columns are as follows:
Architecture Support
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?
Standard Facilities
Are there standardized facilities that meet the requirement?
Partially meet the requirement?
Ubiquitous Facilities
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?
Local/Proprietary Facilities
Has the requirement been met within the architecture by local
applications or with the use of proprietary facilities?
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 *.
EVALUATION OF ESSENTIAL ELEMENTS OF AN OPEN HYPERDOCUMENT SYSTEM
REQUIREMENT ARCHITECTURE STANDARD UBIQUITOUS LOCAL/PROPRIETARY
SUPPORT FACILITIES FACILITIES FACILITIES
PART: URI,
YES: format HTML, IMG,
1. Mixed Objectnegotiation, PART: GIF YES: JPEG in HTML,
Documents typed INSERT, in HTML Java/Safe-Tcl in HTML,
links MIME OLE, OpenDoc, Fresco
link
types*
2. Explicitly YES: HTML,
Structured YES: fragment PART: YES: Panorama, OLE,
Documents identifiers SGML, MIME HTML LINCKS
3. View Control
of Object's PART: YES:DynaWeb,
Form, Sequence,PASS HTTP, NO Java/Safe-Tcl, Style
and Content CGI Sheets
4. The Basic YES: URI, YES: URI,
"Hyperdocument"YES HTML HTML
5.
Hyperdocument PART: YES: local link map,
"Back-Link" PASS Referer NO back-link service
Capability
6. The
Hyperdocument
"Library PASS NO NO NO
System"
7.
Hyperdocument PASS YES: MIME YES: MIME
Mail
8. Personal
Signature PASS NO NO YES: S-HTTP, PEM,
Encryption S/MIME, PGP, PKCS-7
9. Access PART: PART: YES: MD5, SSL,
Control YES Basic Basic S-HTTP, PGP, smart cards,
auth Auth etc.
10. Link
Addresses That
Are Readable
and PART: URI PART: URI PART: URI
Interpretable
by Humans
11. Every objects: YES
Object substructures: PART: URI PART: URI
Addressable
PASS
12. Hard-Copy
Print
Options to Show
Address of
Objects and PASS NO NO YES: HTML2LaTeX
Address
Specification
of Links
CONCLUSIONS
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.
In each area where facilities to meet the requirement are not
ubiquitous, a demonstration of sufficient facilities has taken place.
This gives confidence that the requirements will eventually be met and
become infrastructure.
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.
This archive was generated by hypermail 2.0.0 : Tue Aug 21 2001 - 17:57:54 PDT