ghopp
/
server_playground
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Another abandoned server code base... this is kind of an ancestor of taskrambler.
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.
77 Commits
1 Branch
0 Tags
51 MiB
 
 
 
 
 
 
Tree: 6550e381f0
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '6550e381f0'
${ noResults }
server_playground/doc/www.w3.org/TR/1999/NOTE-xlink-req-19990224

713 lines
31 KiB
Raw Blame History

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML>
<HEAD>
<TITLE>XML XLink Requirements</TITLE>
<LINK rel="stylesheet" type="text/css" media="screen"
href="/StyleSheets/TR/W3C-NOTE">
</HEAD>
<BODY>
<DIV class="head">
<P><A href="http://www.w3.org/">
<IMG height="48" width="72" alt="W3C"
src="http://www.w3.org/Icons/WWW/w3c_home"></A></P>
<H1>XML XLink Requirements<br>Version 1.0</H1>
<H2>W3C Note 24-Feb-1999</H2>
<TABLE>
<TR valign="baseline"><TD>This version:
<TD><A href="http://www.w3.org/TR/1999/NOTE-xlink-req-19990224">
http://www.w3.org/TR/1999/NOTE-xlink-req-19990224</A>
<TR valign="baseline"><TD>Latest version:
<TD><A href="http://www.w3.org/TR/NOTE-xlink-req">
http://www.w3.org/TR/NOTE-xlink-req</A>
<TR valign="baseline"><TD>Editors:
<TD>Steven J. DeRose (Inso Corp. & Brown Univ.) &lt;<a
href="mailto:Steven_DeRose@Brown.edu">Steven_DeRose@Brown.edu</a>&gt;<BR>
The editor gratefully acknowledges the work of Paula Angerstein
(invited expert) &lt;<a
href="mailto:paula.angerstein@ibm.net">paula.angerstein@ibm.net</a>&gt;,
who prepared the first draft of this document.
</TABLE>
<p><small>
<A HREF="http://www.w3.org/Consortium/Legal/ipr-notice.html#Copyright">Copyright</A>
&#169;1999 <A HREF="http://www.w3.org">W3C</A> (<A HREF="http://www.lcs.mit.edu">MIT</A>,
<A HREF="http://www.inria.fr/">INRIA</A>, <A HREF="http://www.keio.ac.jp/">Keio</A>)
, All Rights Reserved. W3C <A HREF="http://www.w3.org/Consortium/Legal/ipr-notice.html#Lega
lDisclaimer">liability,</A>
<A HREF="http://www.w3.org/Consortium/Legal/ipr-notice.html#W3CTrademarks">trademark</A>,
<A HREF="http://www.w3.org/Consortium/Legal/copyright-documents.html">document
use</A> and <A HREF="http://www.w3.org/Consortium/Legal/copyright-software.html">software
licensing</A> rules apply.</small></p>
</DIV>
<HR>
<H2><A name="status">Status of this document</A></H2>
<p>This is a W3C Note produced as
a deliverable of the <a href="http://www.w3.org/XML/Activity#linking-wg">XML
Linking WG</a> according to its charter. A list of current W3C working drafts
and notes can be found at <a href="http://www.w3.org/TR">http://www.w3.org/TR
</a>.</p>
<p>This document is a work in progress representing the current consensus
of the W3C XML Linking Working Group. This version of the XML Link
Requirements document has been approved by the XML Linking working group
and the XML Plenary to be posted for review by W3C members and other interested
parties. Publication as a Note does not imply endorsement by the W3C membership.
Comments should be sent to <a href="mailto:www-xml-linking-comments@w3.org">
www-xml-linking-comments@w3.org</a>, which is an automatically and publicly
archived email list.</p><p>This document is being processed according to the
following review schedule:</p><table border="1" frame="border">
<caption>Review Schedule</caption>
<tbody>
<tr><th>Process</th><th>Closing date</th><th>Status</th><th>Contact</th></tr>
<tr><td>XML Linking WG signoff</td><td>1999/01/21</td><td>done</td><td><a
href="http://www.w3.org/XML/Activity#linking-wg">XML Linking WG</a></td></tr>
<tr><td>XML Plenary signoff</td><td>1999/02/03</td><td>done</td><td><a href="mailto:bill.smith@Sun.COM,veillard@w3.org">
bill.smith@Sun.COM,veillard@w3.org</a></td></tr>
<tr><td>Publish as W3C Note</td><td>1999/02/23</td><td>accepting comments
</td><td><a href="mailto:www-xml-linking-comments@w3.org">www-xml-linking-comments@w3.org
</a></td></tr>
<tr><td>Checkpoint of comments</td><td>1999/03/23</td><td>&nbsp;</td><td>
&nbsp;</td></tr>
</tbody></table><p>Comments about this document should be submitted to the
"contact" listed above for each process.</p>
<div><h4>Abstract</h4>
<p>This document specifies requirements for the XLink specification. Xlink
defines XML-conforming syntax for expressing links among XML documents and
other Internet resources, and defines some of the behavior of applications
that support it.
</p>
</div>
<div><h4>Related documents</h4>
<p><a href="http://www.w3.org/XML/Group/Linking">XML Linking
Working Group Page</a> [member only], for general information about the
activities of the WG.</p>
<p><a href="http://www.w3.org/TR/NOTE-xptr-req">
XPointer Requirements,</a> produced by the XML Linking Working Group. This
document provides requirements governing the work of this WG on the
XPointer specification.</p>
<p><a href="http://www.w3.org/TR/1998/WD-xptr-19980303">
XML Pointer Language (XPointer) Working Draft,</a> prior WDs produced by
the former XML Working Group, and now under the XML Linking WG. Provides a
simple yet powerful mechanism for addressing data portions in XML
documents. </p>
<p><a href="http://www.w3.org/TR/NOTE-xptr-infoset-liaison">
XPointer-Information
Set Liaison Statement,</a> produced by the XML Linking Working Group. This
document enumerates perceived constraints that work on the XPointer
specification has indicated may affect the XML Information Set Working
Group, since it is those information structures that XPointer provides
access to.</p>
<p><a href="http://www.w3.org/TR/1998/WD-xlink-19980303">XML Linking
Language (XLink) Working Draft,</a> the companion specification to this
document. Prior WDs produced by the former XML Working Group, and now under
the XML Linking WG.</p>
<p><a href="http://www.w3.org/TR/1998/NOTE-xlink-principles-19980303">
XML Linking Language (XLink) Design Principles,</a> produced by the former
XML Working Group, and now under the XML Linking WG. This document provides
general design principles governing the work of this WG, involving both the
XLink and XPointer specifications.</p>
</div>
<div><h2>Table of Contents</h2>
<ul>
<li><a href="#overview">1. Overview</a> </li>
<li><a href="#design">2. Design Principles</a> </li>
<li><a href="#term">3. Terminology</a> </li>
<li><a href="#req">4. Requirements</a>
<ul>
<li><a href="#general">A: General user requirements</a></li>
<li><a href="#syntax">B: Mechanical and syntactic requirements</a></li>
<li><a href="#compatibility">C: Compatibility requirements</a></li>
</ul>
<li><a href="#Bibliography">Bibliography</a> </li> </ul>
</div>
<div><h1><a name="overview">1. Overview</a></h1>
<p>This document specifies the requirements for linking among XML documents
and other Internet resources. An XML link, as the term is used here, is the
specification of an <i>explicit relationship</i> between resources or
portions of resources, as well as XLink-defined descriptive information.
The specific identification methods that locate various types of data (such
as URIs, XPointers, and graphical co-ordinates) are outside the scope of
XLink.</p></div>
<div><h1><a name="design">2. Design Principles</a></h1>
<p>The following general design principles, adapted from those of XML,
underly the XLink design. The XML design principles are described
in the W3C Note <a
href="http://www.w3.org/TR/1998/NOTE-xlink-principles-19980303">
XML Linking Language (XLink) Design Principles</a>.</p><ol>
<li><p>XLink must be straightforwardly usable over the Internet.</p></li>
<li><p>XLink must be usable by a wide variety of link usage domains and classes
of linking application software.</p></li>
<li><p>XLink must support HTML 4.0 linking constructs.</p></li>
<li><p>The XLink expression language must be XML.</p></li>
<li><p>The XLink design must be prepared quickly.</p></li>
<li><p>The XLink design must be formal, concise, and illustrative.</p></li>
<li><p>XLinks must be human-readable and human-writable.</p></li>
<li><p>XLinks may reside within or outside the documents in which the
participating resources reside.</p></li>
<li><p>XLink must represent the abstract structure and significance of
links.</p></li>
<li><p>XLink must be feasible to implement.</p></li>
<li><p>XLink must be informed by knowledge of established hypermedia
systems and standards.</p>
<p>These include, but are not limited to, Augment, Dexter, FRESS, HTML,
Hyper-G, HyTime, InterMedia, MicroCosm, OHS, and the Text Encoding
Initiative (see <a href="#Bibliography">Bibliography</a>).</p></li>
</ol></div>
<!--
==========================================================================
-->
<div><h1><a name="term">3. Terminology</a></h1>
<p>While it is not the purpose of this document to establish or constrain the
terminology XLink must use, some terminology is defined here for the
purpose of clarity in the remainder of this requirements specification.</p>
<dl>
<dt>link</dt><dd><p>The concrete description of one or more data resources
or sub-resource portions, and the nature of their relationship for some
given purpose.</p></dd>
<dt>end or link end</dt><dd><p>One of the resources or data resources
described and connected by a link.</p></dd>
<dt>locator</dt><dd><p>A specification that identifies a particular link
end's location, such as a URI.</p></dd>
<dt>role</dt><dd><p>The semantic function that a given end plays in a link,
such as being the thing commented upon, the comment, or a referenced
authority. A role is part of the descriptive aspect of linking, and is not
itself considered a link end.</p></dd>
<dt>traversal</dt><dd><p>The act of navigating from one end of a link to
some other end of the same link. This is commonly accomplished in browsers
by clicking on the data at one link end, but other kinds of traversal are
also possible and useful. XLink may provide means for controlling which
ends of a link can be reached from which other ends; such constraints are
commonly called "traversal rules", and serve to make some ends "available"
and others "unavailable" from a given starting point.</p></dd>
<dt>target or destination</dt><dd><p>The resource or sub-resource to be
reached via a traversal.</p></dd>
<dt>trail</dt><dd><p>An ordered list of sub-resources, each linked to the
next. This construct is typically used to create a path or guided tour
through some data collection.</p></dd>
<dt>available end</dt><dd><p>An end that can be directly reached from the
"current" location (in applications where that is a meaningful notion), is
said to be available (or sometimes, "active"). Rules of some kind may
dictate that not <i>all</i> ends are available at a given time or from a
given starting end.</p></dd>
<dt>aggregate</dt><dd><p>A single end may, in some systems, include
multiple discontiguous data objects, that are to be treated together as a
single end of the link. Such an end is called an "aggregate", and the
resources that are part of it are called its "members". Typically an
aggregate has a unified role and other descriptive information in the link,
while the members have their own relationships involving how they are
assembled or treated as a unit (say, ordering, transformation, selection,
and so on).</p></dd>
<dt>inline/out of line</dt><dd><p>In order to make it possible to express
links all of whose ends are read-only, many hypermedia systems provide a
way to encode links in some place external to the document(s) containing
any of their ends. A link that makes use of this capability is said to be
stored "out of line", while one whose own location is one of its ends is
"inline".</p>
<blockquote>Note: The HTML &lt;A&gt; element is strictly inline; ISMAP
files for graphics contain entries that are somewhat analogous to
out-of-line links, since they link graphic regions to other resources
without being embedded in either the graphic or the other
resource.</blockquote>
</dd>
<dt>transclusion</dt><dd><p>A specific kind of linking in which access of
one end automatically causes another end(s) to be retrieved and embedded,
appearing much as if their data had occurred at the same place as the
initial end that triggered its inclusion. The original definition also
requires that systems provide direct access to the originating document as
a whole, in its original document context (including, for example, its
copyright notice).</p></dd>
<!-- <dt></dt><dd><p></dd> -->
</dl>
<p>The following diagram shows a 3-ended link such as might be used in an
editing or review application. The three ends are
<ul>
<li>Topic: the document portion (commonly a small part of a larger
document), on which the reviewer is making a suggestion;</li>
<li>Comment: the comment itself, saying what the reviewer feels is wrong
(or perhaps right) with the topic data;</li>
<li>Suggestion: the reviewer's suggested change.</li>
</ul>
<img src="NOTE-xlink-req-fig1.jpg"
alt="Diagram of link with 3 locator arcs, each with a role, and each
pointing to an end in some data">
<p>The link accomplishes several things:
<ul>
<li>Identifies the location of the data that makes up each of its ends;</li>
<li>States what role each end plays in the link as a whole;</li>
<li>Explicitly groups the ends.</li>
</ul>
<p>A link may also express much other data about itself or its ends; XLink
may define some such data, and may permit link creators to add their own as
well. An XLink may also place constraints or tests on its ends, such as
requiring that certain ends be in certain data formats, or providing ways
to detect when a locator has failed. But the functions of identifying ends,
describing them and their relationship, and grouping them into an explicit
link, are the basic desiderata of XLink.</p>
</div>
<!--
==========================================================================
-->
<div><h1><a name="req">4. Requirements</a></h1>
<div><h2><a name="general">A: General user requirements</a></h2>
<p>1: An XML link must be able to describe and relate one or more Internet
resources and/or data portions within resources. This implies the following:
</p>
<ol>
<li><p>addressing complete resources</p></li>
<li><p>addressing specific portions of resources (this is largely
accomplished via related specifications such as for URLs and
XPointers).</p></li>
<li><p>expressing links having multiple ends</p></li>
</ol>
<blockquote>Note: Links themselves are also resources, and resources to be
used with XLink must be expressible via URIs (including fragment
identifiers).</blockquote>
<p>2: It must be possible for an XML link itself to serve as one of the
resources pointed to by the link. That is, the link construct itself may
serve to mark up one of the endpoints of the link.</p>
<p>3: It must be possible for an XML link to address into a resource
without requiring modification of that resource. Thus, a link need not
physically occur within any of the resources it points to.</p>
<p>4: An XML link, as an abstract datatype, must make at least the
following information available to an application:</p>
<ul>
<li><p>A specification of each of its ends (as described below).</p></li>
<li><p>An <b>indication </b>of whether or not the link's location is itself
an end of the link.</p>
<blockquote>Note: Making the link's own location an end is a distinct and
common special case, probably worthy of special syntax (even though, of
course, one could always add an explicit end that pointed to the link's
location using generic mechanisms). Supporting links whose own location is
not one of their link ends, is critical so that links can be created to
connect and describe resources without modifying those resources
themselves. In such cases the actual location of the link is generally
insignificant to the application.</blockquote></li>
<li><p>An optional <b>order</b> in which the link's ends are accessed or
made available. The link processor must be able to access each resource
that serves as a link endpoint in an order specified by the link author.
</p>
<blockquote>Note: This order might, for example, be used in a menu of
available destination ends when the user clicks on the data at one end of a
link. [there is not consensus on the need for ordering ends, or how it
relates to ordering of members within ends, if those are to be supported].
</blockquote></li>
<li><p>A required link <b>type </b>that may have meaning to specific
applications (if not specified, the type is specifically "undefined"). This
can indicate the link's purpose so that application-specific processing can
be applied.</p>
<p>For compatibility with HTML, it appears necessary to leave the type
implicit in some cases; such a link is considered to have a type,
specifically "undefined".</p></li>
<li><p>Some human-readable identifying text, or <b>title</b>. This can
be displayed or otherwise used as a description of the link as supplied by
the link author.</p>
<blockquote>Note: Link titles raise issues of internationalization. They
must be able to include text not just in English. They are also very
important as a means of addressing Accessibility concerns for the
print-disabled user. </blockquote>
</li>
</ul>
<p>5: Each end of a link, as an abstract datatype, must make at least the
following information available to an application:</p>
<ul>
<li><p>A <b>role,</b> to specify the end's particular function in relation
to the link and/or the other ends. A rolemay have meaning to specific
applications.</p></li>
<li><p>A <b>title,</b> some human-readable identifying text for the
particular end.
This can be displayed or otherwise used as a description of the link as
supplied by the link author.</p>
<blockquote>Note: Link titles raise issues of internationalization; it is
required that they be able to include text not just in English. They are
also very important as a means of addressing Accessibility concerns for the
print-disabled user. </blockquote>
</li>
<li><p>Some <b>behavior</b> hints that may suggest certain treatment on the
part of link processors. </p>
<p>For example, simple indications of when to access a resource, where to
display it, or what to do with the originating end. The link processor can
pass on hints as how to display and process the link to the application; a
simple example is that a stylesheet in a browsing application could access
them to condition its display or interaction behavior. In some applications
such hints may have no meaning, and are therefore not required.</p></li>
<li><p>A <b>locator</b> that identifies the specific destination
constituting the particular link end. (see also the Note on the next
item)</p>
<li><p>A <b>context locator</b> that identifies the corresponding
containing scope that should be displayed, indexed, or otherwise used to
provide contextual meaning for the resource identified by the locator.</p>
<blockquote>Note: The distinction between this and the last item is similar
to what underlies the typical treatment of fragment identifiers in HTML
&lt;A&gt; links: The client retrieves a context which is typically a whole
document, but then somehow identifies the particular target portion within
it. Another example could be a link in a review or annotation application:
it may point to a particular mis-spelled word, even though a later user is
unlikely to desire retrieval of merely the one word without its document
context. </blockquote>
</li>
</ul>
<p>6: It must be possible to specify the types of destinations a link's
ends can
point to. In particular, a resource may be restricted to a specified set of
content-types, XML element types, namespaces, and so on. </p>
<blockquote>Note: For example, an application might wish to ensure that for
links of type "review-comment", the "topic" end must point to part of an
XML document from the DocBook schema, while the "comment" end must point to
an entire HTML document.</blockquote>
<p>7: XLink should be able to express limited claims about the legal
status of the linked data, particularly in the case of transclusion. For
example, a way for a link creator to assert that they have the right to
copy the data at some link end(s).</p>
<blockquote>Note: Some users have noted that support of transparent
inclusion (transclusion) could conceivably be misconstrued as facilitating
plagiarism. One possible option is to provide a way on transclusion links,
to <i>express</i> a claim about rights. Browsers, for example, could then
mark or prevent transclusions that do not explicitly claim rights. Making
it possible for link creators to be clear seems to be about the best one
can hope for in addressing this question.</blockquote>
<p>8: It must be possible to control the directions of traversal available
among a link's ends. </p>
<blockquote>Note: In HTML the &lt;A&gt; link always has exactly two ends,
and traversal is normally available only from one of them (the one where
the &lt;A HREF...&gt; is). Out of line and multi-ended links enable a wider
variety of potential traversals. The WG is considering what degree of
control is desirable, and whether it shall be specified per link type,
whether it can depend on environmental factors, and so on. </blockquote>
<p>9 [non-mandatory goal]: It must be possible to detect
when a resource a link points to is invalidated or modified.</p>
<p>10: XLink should be expressable in terms of RDF.</p>
</div>
<div><h2><a name="syntax">B. Mechanical and syntactic requirements</a></h2>
<p>1: A link must be specified using XML.
</p>
<p>2: It must be possible to apply XML link semantics to existing
documents by modifying the documents' DTDs only, requiring no modification
to the document instances themselves. </p>
<blockquote>For example by supplying appropriate information in an
element's definition (in the DTD), such as a default ROLE attribute. This
provides for layering of XML link semantics onto large bodies of XML
documents without requiring modification of those documents.</blockquote>
<p>3: Link markup must be unambiguously recognizable within a standalone
XML instance in which it occurs.
</p>
<p>4: Specification of a link must be independent of the specification
of the address(es) of the resource(s) the link connects and describes.</p>
<p>5: It must be possible to assert the existence of a link from a DTD.</p>
<blockquote>[There is not consensus on whether it is enough to be able to
locate link <i>ends</i> that reside in a DTD, or whether there must be a
way to put the physical representation of a <i>link</i> actually within a
DTD (which imposes greater syntactic challenges). </blockquote>
</div>
<div><h2><a name="compatibility">C: Compatibility requirements</a></h2>
<p>1: An XML link must use a URI to address a resource as defined in <a
href="http://www.ietf.org/rfc/rfc1738.txt">IETF RFC 1738: Uniform Resource
Locators.</a></p>
<p>2: An XML link must require using the XPointer specification to identify
specific link end locations in an XML resource.</p>
<p>3: An XML link must provide a straightforward way of representing an
HTML &lt;A&gt; or &lt;IMG&gt; link. Automated translation of HTML links to
XML links must be possible.</p>
<p>4: XLink must liaise with other WGs as appropriate, including RDF and
SYMM.</p>
</div></div>
<!--
================================================================================
================== -->
<div>
<h1><a name="Bibliography">Bibliography</a></h1>
<blockquote>Note: This bibliography only lists works that are readily
accessible, either online or in widely-available print publications. A
wealth of information on major systems and projects is available on the <a
href="http://www.cs.brown.edu/memex/archives.html">Memex and Beyond</a> Web
site.</blockquote>
<h2>Systems</h2>
<p>Akscyn, Robert, Donald McCracken, and Elise Yoder. 1987. "KMS: A
Distributed Hypermedia System for Managing Knowledge in Organizations." In
<i>Proceedings of Hypertext '87</i>, Chapel Hill, NC. November 13-15, 1987.
NY: Association for Computing Machinery Press, pp. 1-20.</p>
<p>DeRose, Steven J. and Andries van Dam. 1999. "Document Structure and
Markup in the FRESS hypertext system." In <i>Markup Languages</i> 1(1),
Winter 1999, pp. 7-46.</p>
<p>Furuta, Richard, Frank M. Shipmann III, Catherine C. Marshall, Donald
Brenner, and Hao-wei Hsieh. 1997. "Hypertext paths and the World-Wide Web:
Experiences with Walden's Paths." In <i>Proceedings of Hypertext '97</i>.
NY: Association for Computing Machinery Press.</p>
<p>Garret, L. Nancy, Karen E. Smith, and Norman Meyrowitz. 1986.
"Intermedia: Issues, Strategies, and Tactics in the Design of a Hypermedia
System." In <i>Proceedings of the Conference on Computer-Supported
Cooperative Work</i>.</p>
<p>Hall, Wendy, Hugh Davis, and Gerard Hutchings. 1996. <i>Rethinking
Hypermedia: The Microcosm Approach</i>. Boston: Kluwer Academic Publishers.
ISBN 0-7923-9679-0.</p>
<p>Marshall, Catherine C., Frank M. Shipman, III, and James H. Coombs.
1994. "VIKI: Spatial Hypertext Supporting Emergent Structure". In
<i>Proceedings of the 1994 European Conference on Hypertext</i>. NY:
Association for Computing Machinery Press.</p>
<p>Yankelovich, Nicole, Bernard J. Haan, Norman K. Meyrowitz, and Steven M.
Drucker. 1988. "Intermedia: The Concept and the Construction of a Seamless
Information Environment." <i>IEEE Computer </i>(January, 1988): 81-96.</p>
<h2>Standards</h2>
<p>Berners-Lee, T. and L. Masinter, editors. December 1994.
"Uniform Resource Locators (URL)". IETF document <a
href="http://www.ietf.org/rfc/rfc1738.txt">RFC 17338.</a></p>
<p>DeRose Steven J. and David G. Durand. 1994. <i>Making HyperMedia Work: A
User's Guide to HyTime</i>. Boston: Kluwer Academic Publishers. ISBN 0-7923-9432-1.</p>
<p><a name="DeRo95">DeRose, Steven J. and David G. Durand.</a> 1
995. "The TEI Hypertext Guidelines." In <i>Text Encoding Initiative:
Background and Context.</i> Boston: Kluwer Academic Publishers. ISBN
0-7923-3689-5. </p>
<p><a name="DeRo98a">DeRose, Steven and Eve Maler (eds).</a> 1998. <a
href="http://www.w3.org/TR/1998/WD-xlink-19980303">"XML Linking Language
(XLink)."</a> World Wide Web Consortium Working Draft. March 1998. </p>
<p><a name="DeRo98b">DeRose, Steven and Eve Maler (eds). 1998.</a> <a
href="http://www.w3.org/TR/1998/WD-xptr-19980303">"XML Pointer Language
(XPointer)."</a> World Wide Web Consortium Working Draft. March 1998.
</p>
<p>Gr&oslash;nb&aelig;k, Kaj and Randall H. Trigg. 1996. "Toward a
Dexter-based model for open hypermedia: Unifying embedded references and
link objects." In <i>Proceedings of Hypertext '96.</i> NY: Association for
Computing Machinery Press. Also available <a
href="http://www.cs.unc.edu/~barman/HT96/P71/Groenbaek-Trigg.html">online.</a></
p>
<p>Halasz, Frank. 1994. "The Dexter Hypertext Reference Model." In
<i>Communications of the Association for Computing Machinery </i>37 (2),
February 1994: 30-39.</p>
<p>Hardman, Lynda, Dick C. A. Bulterman, and Guido van Rossum. 1994. "The
Amsterdam Hypermedia Model: Adding Time and Context to the Dexter Model."
In <i>Communications of the Association for Computing Machinery </i>37.2
(February 1994): 50-63. </p>
<p>International Organization for Standardization. 1992. ISO/IEC 10744.
"Information technology - Hypermedia/Time-based Structuring Language
(HyTime)." Also available <a
href="http://www.ornl.gov/sgml/wg8/docs/n1920/">online.</a></p>
<p>Moline, Judi, Dan Denigni, and Jean Baronas (eds.). 1990. <i>Proceedings
of the Hypertext Standardization Workshop</i>, January 16-18, 1990,
National Institute of Standards and Technology. Washington: U.S. Government
Printing Office. Available from the <a href="http://www.nist.gov">National
Technical Information Service</a> as Publication PB90215864. <a
href="http://www.nist.gov/public_affairs/faqs/qpubs.htm">(ordering
information)</a></p>
<p><a href="mailto:pnuern@daimi.aau.dk">N&uuml;rnberg, Peter J.</a>
Home page of the <a href="http://www.ohswg.org">Open Hypermedia Systems
Working Group.</a></p>
<p>Sperberg-McQueen, C. Michael and Lou Burnard (eds). 1994. <i>Guidelines
for Electronic Text Encoding and Interchange.</i> Chicago, Oxford: Text
Encoding Initiative. Also available <a
href="http://etext.virginia.edu/TEI.html">online.</a>
See especially the section on <a
href="http://etext.virginia.edu/bin/tei-tocs?div=DIV3&amp;id=SAXRS">extended
pointer syntax.</a> Also available for <a
href="ftp://ftp-tei.uic.edu/pub/tei">ftp.</a></p>
<h2>General Hypertext</h2>
<p>Agosti, Maristelle and Alan Smeaton. 1996. <i>Information Retrieval and
Hypertext</i>. Boston: Kluwer Academic Publishers. ISBN 0-7923-9710-X.</p>
<p>Bush, Vannevar. 1945. "<a
href="http://www.ps.uni-sb.de/~duchier/pub/vbush/vbush.shtml ">As We May
Think</a>." <i>Atlantic Monthly </i>176 (July): 101-108. Links to many of
Bush's works are <a href="
http://www.ausbcomp.com/~bbott/wik/bushref.htm">collected here</a>.</p>
<p>Catano, James V. 1979. "Poetry and Computers: Experimenting with the
Communal Text." In <i>Computers and the Humanities </i>13 (9): 269-275.</p>
<p><a name="Conk87">Conklin, Jeff.</a> 1987. "Hypertext: An Introduction
and Survey." <i>IEEE Computer</i> 20 (9): 17-41.</p>
<p><a name="DeRo89">DeRose, Steven J.</a> 1989. "Expanding the Notion of
Links." In
<i>Proceedings of Hypertext '89,</i> Pittsburgh, PA. NY: Association for
Computing Machinery Press.</p>
<p>Engelbart, Douglas C. 1963. "A Conceptual Framework for the Augmentation
of Man's Intellect". In <i>Vistas in Information Handling</i>, Vol. 1 (P.
Howerton, ed.). Washington, DC: Spartan Books: 1-29. Reprinted in Greif,
Irene (ed.), 1988. <i>Computer-Supported Cooperative Work: A Book of
Readings</i>. San Mateo, California: Morgan Kaufmann Publishers, pp. 35-65.
ISBN 0934613575.</p>
<p>Gibson, David, Jon Kleinberg, and Prabhakar Raghavan. 1998. "Inferring
Web Communities from Link Topology." In <i>Proceedings of Hypertext
'98</i>, Pittsburgh, PA. NY: Association for Computing Machinery Press.</p>
<p>Halasz, Frank. 1987. "Reflections on NoteCards: Seven Issues for the
Next Generation of Hypermedia Systems." Address presented at Hypertext '87,
November 13-15, 1987. Reprinted in <i>Communications of the Association for
Computing Machinery </i>31 (7), July 1988: 836-855.</p>
<p>Kahn, Paul. 1991. "Linking Together Books: Experiments in Adapting
Published Material into Intermedia Documents." In Paul Delany and George P.
Landow (eds), <i>Hypermedia and Literary Studies</i>. Cambridge: MIT
Press.</p>
<p>Landow, George P. 1987. "Relationally Encoded Links and the Rhetoric of
Hypertext." In <i>Proceedings of Hypertext '87</i>, Chapel Hill, NC,
November 13-15, 1987. NY: Association for Computing Machinery Press:
331-344.</p>
<p>Meyrowitz, Norman. 1986. "Intermedia: the Architecture and Construction
of an Object-Oriented Hypermedia system and Applications Framework." In
<i>Proceedings of OOPSLA</i>. Portland, OR.</p>
<p>Nelson, Theodore H. 1987. <i>Literary Machines</i>. (available in
multiple editions).</p>
<p>Trigg, Randall H. 1988. "Guided Tours and Tabletops: Tools for
Communicating in a Hypertext Environment." In <i>ACM Transactions on Office
Information Systems</i>, 6.4 (October 1988): 398-414.</p>
<p>Trigg, Randall H. 1991. "From Trailblazing to Guided Tours: The Legacy
of Vannevar Bush's Vision of Hypertext Use." In Nyce, James M. and Paul
Kahn, eds, 1991, <i>From Memex to Hypertext: Vannevar Bush and the Mind's
Machine</i>. San Diego: Academic Press, pp. 353-367. <a
href="http://www.stg.brown.edu/projects/hypertext/landow/cv/Reviews/Nyce_977.html">A thorough review.</a></p>
<p>Yankelovich, Nicole, Norman Meyrowitz, and Andries van Dam. 1985.
"Reading and Writing the Electronic Book." <i>IEEE Computer </i>18
(October, 1985): 16-30.</p>
<p>Zellweger, Polle T. 1989. "Scripted Documents: A Hypermedia Path
Mechanism." In <i>Proceedings of Hypertext '89</i>. NY: Association for
Computing Machinery Press.</p>
</div>
</body>
</html>