idnits 2.17.1
draft-ietf-html-relrev-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in
this document.
Expected boilerplate is as follows today (2024-04-25) according to
https://trustee.ietf.org/license-info :
IETF Trust Legal Provisions of 28-dec-2009, Section 6.a:
This Internet-Draft is submitted in full conformance with the provisions
of BCP 78 and BCP 79.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2:
Copyright (c) 2024 IETF Trust and the persons identified as the document
authors. All rights reserved.
IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3:
This document is subject to BCP 78 and the IETF Trust's Legal Provisions
Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided
without warranty as described in the Simplified BSD License.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand
corner of the first page
** Missing expiration date. The document expiration date should appear on
the first and last page.
** The document seems to lack a 1id_guidelines paragraph about
Internet-Drafts being working documents.
** The document seems to lack a 1id_guidelines paragraph about 6 months
document validity.
** The document seems to lack a 1id_guidelines paragraph about the list of
current Internet-Drafts.
** The document seems to lack a 1id_guidelines paragraph about the list of
Shadow Directories.
== No 'Intended status' indicated for this document; assuming Proposed
Standard
== The page length should not exceed 58 lines per page, but there was 22
longer pages, the longest (page 2) being 60 lines
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an Abstract section.
** The document seems to lack a Security Considerations section.
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
** There are 2 instances of too long lines in the document, the longest one
being 2 characters in excess of 72.
** There are 473 instances of lines with control characters in the document.
Miscellaneous warnings:
----------------------------------------------------------------------------
== Line 134 has weird spacing: '...her end of th...'
== Line 282 has weird spacing: '... ignore any L...'
== Line 304 has weird spacing: '...scussed in Da...'
== Line 334 has weird spacing: '...ocation of a...'
== Line 367 has weird spacing: '...support searc...'
== (22 more instances...)
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- Couldn't find a document date in the document -- date freshness check
skipped.
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
No issues found here.
Summary: 12 errors (**), 0 flaws (~~), 8 warnings (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 INTERNET DRAFT
3 Hypertext links in HTML
4 draft-ietf-html-relrev-00.txt
6 today
8 Murray Maloney Liam Quin
9 SoftQuad Inc. SoftQuad Inc.
10 murray@sq.com lee@sq.com
12 Status of this Memo
13 This document is an Internet Draft. Internet Drafts are
14 working documents of the Internet Engineering Task Force
15 (IETF), its Areas, and its Working Groups. Note that other
16 groups may also distribute working documents as Internet
17 Drafts.
19 Internet Drafts are draft documents valid for a maximum of six
20 months. Internet Drafts may be updated, replaced, or
21 obsoleted by other documents at any time. It is not
22 appropriate to use Internet Drafts as reference material or to
23 cite them other than as a ``working draft'' or ``work in
24 progress.'' Please check the 1id-abstracts.txt listing
25 contained in the internet-drafts Shadow Directories on
26 nic.ddn.mil, venera.isi.edu, nnsc.nsf.net, nic.nordu.net,
27 ftp.nisc.sri.com, or munnari.oz.au to learn the current status
28 of any Internet Draft.
30 This is a working document only, it should neither be cited
31 nor quoted in any formal document.
33 This document will expire before 7 June 1996.
35 Distribution of this document is unlimited.
37 Please send comments to the author(s).
39 Table of Contents
40 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
41 2. Anchors and Targets . . . . . . . . . . . . . . . . . . . . . 3
42 2a. Anchors . . . . . . . . . . . . . . . . . . . . . . . . . 3
43 2b. Targets . . . . . . . . . . . . . . . . . . . . . . . . . 4
44 3. The LINK and A Elements and Their Attributes . . . . . . . . 5
45 3a. The LINK Element . . . . . . . . . . . . . . . . . . . . . 5
46 3b. The A Element . . . . . . . . . . . . . . . . . . . . . . 6
47 3c. Common Attributes . . . . . . . . . . . . . . . . . . . . 6
48 4. The REL and REV Attribute Values . . . . . . . . . . . . . . . 8
49 4a. Legacy . . . . . . . . . . . . . . . . . . . . . . . . . . 8
50 4b. Browser-defined Links . . . . . . . . . . . . . . . . . . 9
51 4c. Navigational Node Links . . . . . . . . . . . . . . . . . 9
52 4d. Hierarchy Links . . . . . . . . . . . . . . . . . . . . . 10
53 4e. Sequence Links . . . . . . . . . . . . . . . . . . . . . . 11
54 4f. Related Documents . . . . . . . . . . . . . . . . . . . . 12
55 4g. Meta Documents . . . . . . . . . . . . . . . . . . . . . . 14
56 4f. Other REL and REV Values Under Discussion . . . . . . . . 16
57 5. Hypertext Includes . . . . . . . . . . . . . . . . . . . . . 18
58 5a. INCLUDE as a REL or REV Value . . . . . . . . . . . . . . 18
59 5b. INCLUDE as an Element . . . . . . . . . . . . . . . . . . 19
60 5c. SGML external entitities . . . . . . . . . . . . . . . . . 19
61 6. Hypertext Paths . . . . . . . . . . . . . . . . . . . . . . . 19
62 7. Proposed New Attributes for A and LINK Elements . . . . . . . 20
63 7a. ACTION or STYLE or PROCESS or PRESENT . . . . . . . . . . 20
64 7b. TARGET . . . . . . . . . . . . . . . . . . . . . . . . . . 21
65 7c. DINGBAT . . . . . . . . . . . . . . . . . . . . . . . . . 21
66 7d. HILITE or HIGHLIGHT . . . . . . . . . . . . . . . . . . . 21
67 7e. METHOD . . . . . . . . . . . . . . . . . . . . . . . . . . 22
68 7f. SRC . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
69 7g. WHEN . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
70 7h. OBSOLETES, UPDATES and DERIVED-FROM: . . . . . . . . . . . 23
71 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 23
73 Hypertext links in HTML
75 This is a discussion paper: It was initiated through discussion on the
76 HTML Working Group mailing list.
78 Hypertext link relationships, specified by using the REL and REV
79 attributes of the LINK and A elements, were conceived of as an early
80 feature of the HTML language. Amidst all of the various and sundry
81 efforts that have been undertaken to advance HTML and the World Wide
82 Web, the definition of a small set of widely accepted hypertext
83 relationships has yet to be agreed upon and deployed in user agents.
85 Hypertext link relationships, and the attendant REL and REV attributes
86 of the LINK and A elements, are discussed in Dave Raggett's Internet
87 Draft on HTML 3.0. In addition, The Santa Cruz Operation, Inc (SCO) has
88 developed an HTML user agent, based on Mosaic, which incorporates the
89 use of the REL attribute of the LINK element.
91 The first draft of this paper was based on Dave Raggett's paper and on
92 the author's experience with a partial implementation at SCO. Others
93 have contributed to the development of this paper through discussions on
94 the html-wg mailing list and through private correspondence with the
95 author. (See the Acknowledgements section.)
97 1. Introduction
98 The hypertext link mechanism is the connective tissue used to weave
99 the World Wide Web. A hypertext link is an object which specifies
100 a connection between any arbitrary addressable objects, locations,
101 or resources.
103 A hypertext link typically consists of an anchor and a target, each
104 of which may be further classified and between which relationships
105 may be identified. In HTML, there are several language elements
106 which are used to identify anchors and targets and thus support the
107 hypertext link mechanism.
109 The anchor of a hypertext link is typically presented to the user,
110 through an HTML user agent, as a highlighted object (a word, phrase,
111 graphic image, etc.). Not all anchors of hypertext links must be
112 represented as highlighted within the document or the application.
113 An HTML user agent may, as appropriate, act upon a hypertext link by
114 taking immediate action, such as presenting a concurrent window. A
115 user agent may, in some cases, simply ignore an anchor and its
116 hypertext link.
118 An HTML user agent is free to provide whatever mechanism it chooses
119 to allow the user to traverse from anchor to target. Typically,
120 graphical applications provide for user interaction via a pointing
121 device such as a mouse. Typically, non-graphical text-based
122 applications provide for user interaction via keyboard and arrow
123 selection.
125 Different hypertext links may have different behavior associated
126 with them. For example, a link to a Table of Contents may be
127 presented as an icon, with an appropriate label, in a tool bar.
128 Another application may present the same link as a simultaneous view
129 of the document in an alternate window or a concurrent pane. A
130 hypertext link may also initiate a software program, or present
131 audio, graphics, video, print, speech synthesis or braille.
133 HTML provides a mechanism for specifying the relationship between an
134 anchor and a target as seen from either end of the hypertext link.
135 The LINK and the A elements each provide a REL and a REV attribute
136 which may be set with values to identify these relationships. The
137 IMG element and the SRC attribute can also be used to form links.
139 This purpose of this document is to discuss and formalize hypertext
140 anchors as currently implemented on the World Wide Web, and to
141 propose REL/REV relationships that are useful and consistent with
142 current usage. This paper is intended to describe hypertext links,
143 anchors and targets, classes and relationships. It is also intended
144 to provide suggestions or hints for authors and publishers, and for
145 developers of HTML user agents to guide them in using the hypertext
146 link mechanism effectively.
148 NOTE: This document does not address issues associated with
149 non-practiced usages of hypertext anchors, in particular the
150 inclusion/embedding of program applications (e.g. Java applets),
151 within HTML documents.
153 2. Anchors and Targets
154 2a. Anchors
155 An anchor is any object which acts as a hypertext link to a
156 target. An anchor may be a highlighted phrase within an HTML
157 document, an icon on an HTML user-agent tool-bar or menu item, an
158 active graphic, or an image map. An anchor may also be an object
159 which is included by reference, such a graphic image.
161 There are four ways to specify an anchor in HTML:
162 * the A element
163 * the LINK element
164 * the SRC attribute as used on
165 * the IMG element
166 * the UL element (HTML 3.0 proposal)
167 * the LI element (HTML 3.0 proposal)
168 * the NOTE element (HTML 3.0 proposal)
169 * the ISMAP attribute as used on the IMG element
171 An anchor is typically specified using the A element. This form
172 of anchor is used to highlight an object (word, phrase, graphic
173 image, etc.) which may be activated by a user to traverse the
174 link by using the following form:
175 object to highlight
177 An anchor may also be specified using the LINK element. This form
178 of anchor is used to establish a hypertext link between an entire
179 HTML document and another addressable object or resource. A LINK
180 element is considered document meta-information (it does not mark
181 a link relationship specific to any part of the body), and is
182 therefore restricted to lie within the document HEAD. Because
183 the LINK element is only allowed within the HEAD of an HTML
184 document, and because it has no content, it is not usually
185 represented within the body of an HTML document as seen through a
186 user agent. Its purpose is solely to inform the user agent that a
187 link exists. The user agent may process or ignore these links as
188 it sees fit, but it may, for example, present an icon on a
189 toolbar for the user to traverse the link. An example of LINK
190 usage is:
191
192
194 An anchor may also be specified using the IMG element. This form
195 of anchor is used to establish a hypertext link to include a
196 graphic image. Its purpose it solely to inform the user agent
197 that a graphic image may be placed at the current location if the
198 user agent is capable of doing so, and if the user has enabled
199 viewing of graphic images. An example of this form of IMG usage
200 is:
201
203 An anchor may also be specified by providing a value to the SRC
204 attribute on any HTML element which supports that attribute.
205 For example:
206
259 A target may also be specified as an attribute to a LINK element. 260 A LINK element may only be used within the head of an HTML 261 document, and it has no content. For example: 262 263
264 265 266 268 3. The LINK and A Elements and Their Attributes 269 The LINK and A elements share a set of common attributes. Except 270 where noted, the semantics of those attributes is the same. 272 3a. The LINK Element 273 The LINK element indicates a hypertext link relationship between 274 the document in which it is found and some other object. Any 275 number of LINK elements may be used within the head of an HTML 276 document. The LINK element is empty (does not have a closing 277 tag). The LINK element takes the same attributes as the A 278 (anchor) element. 280 The hypertext link described by the LINK element is not typically 281 represented within the text area of an HTML user agent. Instead, 282 an HTML user agent is free to either ignore any LINK element and 283 the hypertext link associated with it, or to represent the 284 hypertext link in some other way. 286 Presenting hypertext links as active icons in a toolbar is one 287 way to present them to the user. Another may be to present the 288 target document in a concurrent window, such as with a table of 289 contents. 291 3b. The A Element 292 The A element is used to indicate the start (anchor) or end 293 (target) of a hypertext link within the body of an HTML 294 document. 296 The hypertext link described by the A element is typically 297 represented as a highlighted object (word, phrase, graphical 298 image, etc.) within the text area of an HTML user agent. 300 3c. Common Attributes 301 For the purposes of this discussion, the following is a list with 302 descriptions of the most important common attributes. All of the 303 attributes listed here are part of HTML 2.0 except for CLASS, ID 304 and MD, which are discussed in Dave Raggett's Internet Draft on 305 HTML 3.0. 307 CLASS 308 The CLASS attribute value is used to subclass the hypertext 309 link. The CLASS attribute is most often used as a generalized 310 identifier to which style information may be attached by a 311 stylesheet mechanism. 313 The CLASS attribute may also be used to subclass LINK 314 elements, thereby differentiating hypertext links with common 315 REL or REV values. This may provide unambiguous syntax, for 316 example, for multiple LINK elements with REL=NEXT within a 317 document. Thus, alternate paths through a document can be 318 coded within the document. For example: 319 320 321 322 324 Multiple CLASS values may be specified. The potential list of 325 CLASS attribute values is open-ended. However, practical 326 application will likely require definition and specification 327 of at least a small set of accepted keywords, and agreement 328 on processing expectations for arbitrary keywords. The 329 keywords used in the previous example are typical of the 330 type of keywords which may be specified, but are not 331 proposed. 333 HREF 334 The HREF attribute value specifies the location of a 335 destination or resource, expressed in the Universal Resource 336 Identifier (URI) notation. Only one HREF value may be 337 specified. An HTML user agent may present the value of the 338 HREF attribute in an information area when the user positions 339 the mouse over the anchor or otherwise indicates interest in 340 the anchor. 342 ID 343 The ID attribute specifies an SGML identifier used as the 344 target of hypertext links or for naming particular elements 345 in associated style sheets. Only one ID value may be 346 specified. The attribute value must be unique within the 347 document. 349 MD 350 The MD attribute specifies a message digest or cryptographic 351 checksum for the target of the hypertext link. This attribute 352 is used by a user agent to verify that the linked object is 353 the same one that the author intended. 355 NAME 356 The NAME attribute specifies a named location within an HTML 357 document and is used in forming addresses to target specific 358 locations within an HTML document. Only one NAME value may be 359 specified. The attribute value must be unique within the 360 document. 362 REL 363 The REL attribute specifies the relationship of the target to 364 the anchor. For example, REL=NEXT is used to indicate that 365 the target is the next logical document in an author- 366 specified sequence. The REL attribute can also be used to 367 support search for links serving particular relationships. 369 Multiple REL values may be specified. Aggregate links can be 370 formed by including multiple LINK elements with equivalent 371 REL values. Activating the link, in that case, may lead to a 372 virtual menu from which the user can make a selection. 374 The nature of a link relationship is not always obvious from 375 the attribute value. Section 4 (Meaning of REL and REV 376 Attribute Values) describes commonly accepted values. 377 Designers of HTML user agents can use these descriptions as a 378 guide to implementation of browser or agent behavior. 380 REV 381 The REV attribute specifies the relationship of the anchor to 382 the target. For example, REV=TOP is used to indicate that the 383 anchor is the top of an author-specified hierarchical tree 384 of which the target is a branch or node. 386 Multiple REV values may be specified. A Table of Contents may 387 contain a series of anchors which specify REV=TOC. 389 The nature of a link relationship is not always obvious from 390 the attribute value. Section 4 (Meaning of REL and REV 391 Attribute Values) describes commonly accepted values. 392 Designers of HTML user agents can use these descriptions as a 393 guide to implementation of browser or agent behavior. 395 TITLE 396 The TITLE attribute is typically used to describe the linked 397 object specified by the HREF attribute. The attribute value 398 is a character string which may include spaces and 399 punctuation. An HTML user agent may present the value of the 400 TITLE attribute in an information area when the user 401 positions the mouse over the anchor or otherwise indicates 402 interest in the anchor. Authors/publishers can thereby 403 provide greater context to the user to aid them in making 404 decisions about whether to traverse a hypertext link. 406 An HTML user agent may also use the value of the TITLE 407 attribute to set the value of an email subject field when the 408 HREF value uses the `mailto:' scheme. In this way, the 409 subject field may be preset with value that the author's mail 410 agent can recognize and process. 412 Although the HREF and TITLE attributes have been singled out in 413 the list above, any of these attribute values may be presented in 414 an information area when the user positions the mouse over the 415 anchor or otherwise indicates interest in the anchor. For 416 example, an HTML user agent which is also an HTML editor may 417 display the value of ID or NAME attributes. 419 4. The REL and REV Attribute Values 421 The potential list of valid values for REL and REV is open-ended, 422 and this document is not intended to preclude the use or adoption of 423 other or additional values. In fact, it is anticipated that 424 hypertext applications which support specific knowledge domains will 425 need to develop specialized sets of keywords. It is hoped that the 426 development of extensions will not occur in isolation, and that 427 coordination of extensions among various interested parties will 428 prevent namespace contention or collision. 430 Further, HTML user agents should continue to be liberal in accepting 431 new or alternate values, inasmuch as any name token is a legal 432 value. The HTML specification declares that REL/REV values are SGML 433 name tokens. That is, within the previously described syntactical 434 constraints, a REL or REV relationship value may be any arbitrary, 435 author-defined value that the author or publisher considers 436 important. In some cases, the HTML user agent may choose to present 437 relationships that it recognizes in a richer style, while 438 continuing to present unfamiliar ones in the default style. 440 The REL and REV attributes are defined as NAMES in the SGML DTD for 441 the HyperText Markup Language (HTML). As such, the legal values 442 which may be assigned to the REL or REV attribute are zero or more 443 name tokens. Name tokens are case-insensitive, must begin with an 444 alpha character, may include digits (0-9), period or hyphen, and may 445 be separated by spaces. The name tokens listed and described in this 446 section are being recommended as commonly accepted relationships 447 between and among objects in a hypertext collection. 449 When a single name token is specified as a REL or REV attribute, 450 double quotes surrounding the attribute value are optional. When 451 multiple name tokens are specified, double quotes are mandatory. 452 previous 453 previous 454 next 456 4a. Legacy 457 The following are REL values which were known to be used as 458 values of the REL and REV attributes on the World Wide Web in 459 December 1995. 461 MADE 462 The REV=MADE relationship has been used to identify the author 463 or "maker" of an HTML document. Typical HREF values include a 464 `mailto:' URI or the URL of the author's home page. Example: 465 Author 467 NEXT/PREVIOUS/TOC/INDEX/NAVIGATOR 468 These values are described below, are used by SCO in its online 469 documentation and context- sensitive help system. 471 4b. Browser-defined Links 473 Some keywords are reserved and should not be used as REL/REV 474 values. 476 HTML user agents typically provide a mechanism for navigating 477 through the recent history of a user's access to documents; 478 traditionally these operations are referred to as "back" and 479 "forward". These mechanisms allow a user to step back through the 480 documents which led to the current location and then forward 481 again to retrace the path. Additionally, most user agents provide 482 a mechanism to immediately return to a user-defined location, 483 traditionally referred to as the home page, or "home". Since 484 these browser actions are internally implemented by the browser, 485 REL/REV keywords associated with these relationships are 486 disallowed. 488 HOME 489 RESERVED. Defined by the user (for example, using an 490 environment variable or preference, e.g. WWW_HOME). 491 This relationship may not be overridden; HTML user agents 492 should ignore any author-supplied REL=HOME setting. 494 BACK 495 RESERVED. Defined by the browser. This relationship may not 496 be overridden; HTML user agents should ignore any 497 author-supplied REL=BACK setting. 499 FORWARD 500 RESERVED. Defined by the browser. This relationship may not 501 be overridden; HTML user agents should ignore any 502 author-supplied REL=FORWARD setting. 504 4c. Navigational Node Links 505 Navigational nodes are commonly used document objects which are 506 designed by authors to assist the user in navigating through a 507 closed or extended document set. The most familiar and common 508 form of navigational node is a table of contents, which is a well 509 known publishing device used for enumerating and ordering the 510 contents of a closed document set. 512 CONTENTS or TOC 513 The TOC relationship identifies a Table of Contents. 515 When REL=TOC, the target document is the Table of Contents for 516 the current document, or for the collection of documents of 517 which the current document is a member. 519 When REV=TOC, the current document is a Table of Contents and 520 the target document is a related document. 522 When REL=TOC and REV=TOC it indicates that the current 523 document is a Table of Contents and the target document is 524 also a Table of Contents. Additional REL/REV values may be 525 used to specify the relationship between the two, such as 526 PARENT/CHILD. 528 If the hypertext link is specified with REL in a LINK element, 529 an HTML user agent may present an icon in a tool bar. Or, if 530 capable, an HTML user agent may present the Table of Contents 531 in a concurrent window or pane, highlighting the current 532 document. 534 INDEX 535 The INDEX relationship identifies an index. 537 When REL=INDEX, the target document is an index for the 538 current document, or for the collection of documents of which 539 the current document is a member. 541 When REV=INDEX, the current document is an index. Additional 542 REL/REV values may be used to further specify the relationship 543 between the two ends of the link. 545 If the hypertext link is specified with REL in a LINK element, 546 an HTML user agent may present an icon in a tool bar. An index 547 may be presented as an HTML document which is organized and 548 presented in a style reminiscent of a paper-based index. An 549 index may also be presented as a form-based query into a full- 550 text search database. 552 NAVIGATOR 553 The NAVIGATOR relationship identifies a navigational aid. 555 When REL=NAVIGATOR, the target document is a navigational aid. 556 A navigational aid may consist of a whole or partial Table of 557 Contents, a list of related documents, an indication of the 558 current document's location within a document hierarchy, or 559 any other information which may be useful to the user. 561 When REV=NAVIGATOR, the current document is a navigational aid. 563 If the hypertext link is specified with REL in a LINK element, 564 an HTML user agent may present an icon in a tool bar. 566 4d. Hierarchy Links 567 It is quite common for documents to be developed or defined 568 using a hierarchical model, or tree-like structure. The keywords 569 listed below may be used within HTML documents to identify the 570 hierarchical relationship of closely related nodes, such as the 571 immediate parent, siblings and children. In addition, the TOP 572 keyword may be used to identify the logical top (or root, 573 depending on your perspective) of a hierarchical or tree-like 574 structure. 576 The entire set of relationships may be used by a user agent to 577 build a map of the hierarchical structure(s) of which the 578 current document is a node. Hypertext links to documents 579 identified with PARENT and TOP values are more likely to be 580 accessible through an icon or other mechanism than documents 581 identified with CHILD or SIBLING. 583 CHILD 584 The CHILD relationship identifies a subordinate or 585 subdocument. Any document may have multiple CHILD documents 586 within the same hierarchy. 588 When REL=CHILD, the target document is a hierarchical child, 589 or subdocument, of the current document. 591 When REV=CHILD, the current document is the hierarchical 592 child, or subdocument, of the target. 594 PARENT 595 The PARENT relationship identifies the superior or container 596 node. 598 When REL=PARENT, the target document is the hierarchical 599 parent, or container, of the current document. 601 When REV=PARENT, the current document is the hierarchical 602 parent, or container, of the target. 604 If the hypertext link is specified with REL in a LINK element, 605 an HTML user agent may present an icon in a tool bar. 607 SIBLING 608 The SIBLING relationship identifies a sibling in the current 609 hierarchy. Any document may have multiple SIBLING documents 610 within the same hierarchy. 612 When REL=SIBLING, the target document is a child of a common 613 parent, or a hierarchical peer of the current document. REL 614 and REV have equivalent meanings for the SIBLING 615 relationship. 617 TOP or ORIGIN 618 The TOP relationship identifies the logical top of a 619 hierarchical tree of which the current document is a branch. 620 BEGIN is a functional equivalent to TOP, if only one of these 621 values is specified. 623 When REL=TOP, the target document is the logical top node of 624 the tree. When REV=TOP, the current document is the logical 625 top of the tree. 627 If the hypertext link is specified with REL in a LINK element, 628 an HTML user agent may present an icon in a tool bar. 630 NOTE: ORIGIN has been suggested as an alternative to TOP to 631 provide metaphorical consistency with PARENT/CHILD/SIBLING. 632 Comments are encouraged. 634 4e. Sequence Links 635 Given a set of documents, it is possible and often desirable to 636 specify linear sequences to navigate through the set. A book, for 637 example, is often organized as a linear sequence. With sequence 638 links in each document, a user agent can step through or gather 639 an entire book programmatically. 641 BEGIN or FIRST 642 The BEGIN relationship identifies the author- defined start of 643 a sequence of documents of which the current document is a 644 node. TOP is a functional equivalent to BEGIN when only one of 645 these values is specified. 647 When REL=BEGIN, the target document is the beginning of the 648 sequence. When REV=BEGIN, the current document is the 649 beginning of the sequence. 651 If the hypertext link is specified with REL in a LINK element, 652 an HTML user agent may present an icon in a tool bar. 653 END or LAST 654 The END relationship identifies the author defined end of a 655 sequence of documents of which the current document is a node. 656 TOP is a functional equivalent to END when only one is 657 specified. 659 When REL=END, the target document is the end of the sequence. 660 When REV=END, the current document is the end of the sequence. 662 If the hypertext link is specified with REL in a LINK element, 663 an HTML user agent may present an icon in a tool bar. 665 NEXT 666 The NEXT relationship identifies the next document in an 667 author-defined sequence of documents, such as a linear book. 669 When REL=NEXT, the target document is next after the current 670 document. When REV=NEXT, the current document is next after 671 the target. 673 If the hypertext link is specified with REL in a LINK element, 674 an HTML user agent may present an icon in a tool bar. 676 PREVIOUS or PREV 677 The PREVIOUS relationship identifies the previous document in 678 an author-defined sequence of documents, such as a linear 679 book. 681 When REL=PREVIOUS, the target document is previous to the 682 current document. 684 When REV=PREVIOUS, the current document is previous to the 685 target. 687 If the hypertext link is specified with REL in a LINK element, 688 an HTML user agent may present an icon in a tool bar. 690 4f. Related Documents 691 BIBLIOENTRY 692 The BIBLIOENTRY relationship identifies a bibliographic entry. 694 BIBLIOENTRY would most typically be specified on an A element, 695 as it would specify a hypertext link between a citation and a 696 bibliographic entry describing the citation. Example: 697 As We 698 May Think 700 The resource identified by this link may take any form desired 701 by the author/publisher. A bibliographic entry may be presented 702 in the style of a paper-based bibliographic entry, or it may be 703 presented as the result of a database query. 705 BIBLIOGRAPHY 706 The BIBLIOGRAPHY relationship identifies a bibliography. 708 The resource identified by this link may take any form desired 709 by the author/publisher. A bibliography may be presented as an 710 HTML document which is organized and presented in a style 711 reminiscent of a paper-based bibliography. A bibliography may 712 also be presented as a form-based query into a bibliographic 713 database. 715 If the hypertext link is specified with REL in a LINK element, 716 an HTML user agent may present a labeled icon in a tool bar. 718 CITATION 719 The CITATION relationship identifies a bibliographic citation. 721 When REL=CITATION, the target is a bibliographic citation. The 722 anchor, in this case, may be a bibliographic entry. The anchor 723 may also be a reference, thus allowing the reader a way to 724 locate the citation: 725 ... as described by Tim Berners-Lee 726 [1] 727 ... 729 When REV=CITATION, the anchor is a citation. Typically, the 730 anchor would also be enclosed within a CITE element as shown in 731 the example below. The example shown here also corresponds to 732 the previous example, serving as its target by use of the NAME 733 attribute. 734 ... is described in Tim Berners-Lee's 735 The 736 HyperText Markup Language 737 ... 739 NOTE: an alternative (and preferred) approach would be to add a 740 URI-valued attribute (HREF?) to the HTML CITE element. 742 DEFINITION 743 The DEFINITION relationship identifies a definition of a term. 745 Definitions may be, but are not necessarily, contained within a 746 glossary. DEFINITION would most typically be specified on an A 747 element, as it would specify a hypertext link from a term to 748 its definition. 749 HTTP 751 FOOTNOTE 752 The FOOTNOTE relationship identifies a footnote. 754 When REL=FOOTNOTE is specified on an A element, the anchor is a 755 footnote marker and the target is a footnote. This can be used 756 to link from the footnote marker (or a highlighted word, 757 phrase, etc.) to an HTML document which contains the footnote 758 text, or to a portion of the same document (see REV=FOOTNOTE). 760 When REL=FOOTNOTE is specified on a LINK element, it can 761 specify a hypertext link to a set of footnotes which are 762 related to the current document, or to a set of end-notes. 764 When REV=FOOTNOTE is specified on an A element, the anchor is a 765 footnote; that is, the actual content of the footnote, as 766 opposed to a footnote marker. In this case, the target 767 specified by the HREF value, if any, is the footnote marker. 769 It has been suggested that the combination of REV=FOOTNOTE and 770 NAME=... on an A element may be used to imply that the 771 enclosed content not be rendered until a link to it is 772 explicitly traversed, at which time it can be presented in a 773 popup window. This would allow for the inclusion of footnote 774 text within a document that would not be visible until the 775 reader wanted it to be presented. Developers of user agents are 776 free to experiment with this proposed feature, but there is no 777 requirement that it be implemented. 779 GLOSSARY 780 The GLOSSARY relationship identifies a glossary. 782 When REL=GLOSSARY, the target document is a glossary. When 783 REV=GLOSSARY, the current document is a glossary. 785 If the hypertext link is specified with REL in a LINK element, 786 an HTML user agent may present an icon in a tool bar. 788 A glossary may be directly presented as an HTML document which 789 is organized and presented in a style reminiscent of a 790 paper-based glossary. 792 A glossary may also be accessed through an intermediary query 793 mechanism. For example, the user highlights a word or phrase 794 and presses the glossary button, thereby accessing the linked 795 object and passing the highlighted text as an argument. The 796 server returns the glossary entry relevant to the highlighted 797 word. 799 4g. Meta Documents 800 There are classes of information which are not intrinsic to a 801 document, but for which a clear and unambiguous association is 802 often useful or even necessary. This section defines a small set 803 of keywords which are related to ownership and legal notices. 805 Any attempt to rigorously define a closed set of meta- data 806 classes, types, and formats is doomed to failure, partly due to 807 the need for ongoing experimentation. Hence, the META keyword 808 may be used to identify meta documents which do not necesarily 809 have a clear or unambiguous definition. The content of the target 810 node may be as specific format as a MARC record or an FGDC 811 record, or it may be an author-defined format. 813 For each of the relationship keywords listed in this section, if 814 the relationship is specified with REL in a LINK element, an HTML 815 user agent may present a labeled icon in a tool bar. 817 AUTHOR 818 The AUTHOR relationship identifies a hypertext link to 819 an author. 821 The hypertext link may be to the author's home page, a 822 biography, an audio or video clip, or an agent which sends mail 823 to the author (e.g., using the `mailto:' scheme). 825 COPYRIGHT 826 The COPYRIGHT relationship identifies a hypertext link to a 827 copyright notice. 829 While it is arguable whether a copyright notice is required in 830 every HTML file to assert copyright protection on it, there is 831 clearly a desire to express copyright notice among a sufficient 832 portion of the user community to justify support. 834 A basic copyright notice for this document may simply state: 835 "Copyright 1995 by Murray C. Maloney". It may be desirable, 836 in place of or in addition to such a notice, to have a 837 hypertext link between each HTML document in a set and a single 838 copyright notice, as in the following examples: 839 840 841 Copyright 1995 by Murray C. Maloney 843 DISCLAIMER 844 The DISCLAIMER relationship identifies a hypertext link to a 845 legal disclaimer. Usage is expected to be similar to that of 846 the COPYRIGHT hypertext link. As with the copyright notice, 847 there is no intention or expectation that such a link would be 848 the only way to express a disclaimer. 850 EDITOR 851 The EDITOR relationship identifies a hypertext link to an 852 editor. Usage is expected to be similar to that of the AUTHOR 853 hypertext link. 855 META 856 The META relationship identifies a hypertext link to a node 857 which contains meta-information related to the current 858 document. This is intended to be a generalized meta-data 859 relationship descriptor. 861 PUBLISHER 862 The PUBLISHER relationship identifies a hypertext link to a 863 publisher. Usage is expected to be similar to that of the 864 AUTHOR hypertext link. 866 TRADEMARK 867 The TRADEMARK relationship identifies a hypertext link to a 868 trademark notice. Usage is expected to be similar to that of 869 the COPYRIGHT hypertext link. 871 4f. Other REL and REV Values Under Discussion 872 The POINTER keyword is an invention of the author. 874 The BANNER, BOOKMARK, HOTLIST and STYLESHEET keywords are 875 described in Dave Raggett's Internet Draft on HTML 3.0. Recent 876 discussions tend to indicate that these keywords may not be 877 appropriate for use as REL/REV values. Dave Raggett's further 878 explanation and justification is needed before any further 879 discussion or decision can be made as to the future status of 880 these keywords. 882 The LANG attribute is described in Dave Raggett's Internet Draft 883 on HTML 3.0. It has been applied to various HTML elements, not 884 including the LINK and A elements. The author suggests that LANG 885 is a useful attribute to apply to the LINK and A elements. See 886 also the discussion of REL=TRANSLATION. 888 BANNER 889 The BANNER relationship identifies a document banner. 891 When REL=BANNER, the target document is to be included within 892 the current document as a banner. A banner is typically used 893 for corporate logos, custom toolbars, and other information 894 which would not typically be scrolled with the body of a 895 document. 897 When REV=BANNER, the current document is a banner. This may be 898 used, in future, to provide error-checking or to prevent the 899 use of a document as a banner unless it has been explicitly 900 identified as a valid source. (Or not! Sorry, I was reaching 901 for a useful meaning.) 903 Compelling arguments have been made against the need for a 904 REL=BANNER value, which is simply a special case of the INCLUDE 905 mechanism. 906 BOOKMARK 907 The BOOKMARK relationship identifies a bookmark. 909 Bookmarks are used to provide direct links to key entry points 910 into an extended document. The TITLE attribute may be used to 911 label the bookmark. Several bookmarks may be defined in each 912 document, and provide a means for orienting users in extended 913 documents. 915 HOTLIST 916 RESERVED: This keyword has been proposed by Dave Raggett. Its 917 meaning and purpose require further explanation. A placeholder 918 is being maintained until such time as Dave has had an 919 opportunity to provide further explanation, examples, 920 discussion and justification. 922 If the hypertext link is specified with REL in a LINK element, 923 an HTML user agent may present an icon in a tool bar. 925 LANG 926 The LANG attribute indicates the language of the target 927 document. 929 The LANG attribute is optional and has no default value. It may 930 be used for purely informational purposes by an HTML user 931 agent, or by a robot for language classification. 933 Used in combinatiuon with a proposed REL=TRANSLATION and a 934 user's language preference setting, an HTML user agent may 935 intelligently select from a collection of otherwise equivalent 936 hypertext links expressed with the LINK element. If the user's 937 language preference is not available, the user agent may 938 present a virtual menu of language options. 940 See the Internet Draft on the Internatiolisation of HTML for 941 a definition of the values of this attribute. 943 POINTER 944 The pointer relationship identifies a hypertext pointer. That 945 is, this is a way to do indirection in HTML. 947 When REV=POINTER, the anchor is a pointer to the target 948 document. When a hypertext link is traversed to a LINK or A 949 element with REV=POINTER, the target specified by the HREF 950 value should be traversed, and so on, until a target without 951 REV=POINTER is retrieved. 952 954 When REL=POINTER, the target is a pointer to the real target. 955 This value can be used by a user agent to perform a pre-fetch 956 of the specified target for evaluation until the real target is 957 reached. 959 NOTE: The authors propose that the NAME attribute be removed 960 from the LINK element, or that a practical use for it should be 961 defined. For example, hypertext indirection can be specified by 962 providing both a NAME and an HREF value on the LINK element, in 963 combination with a specific REL or REV value, such as POINTER. 964 Some support exists among members of the HTML Working Group to 965 provide for hypertext indirection with the LINK element. There 966 is no other reason for an author to define a target by using 967 the NAME attribute on a LINK element, since the resulting 968 target address is functionally equivalent to the address of the 969 document in which such a target is defined. 971 STYLESHEET 972 The STYLESHEET relationship identifies a stylesheet. 974 When REL=STYLESHEET, the target document is a stylesheet. When 975 associated with a LINK element, the author/publisher is 976 expressing an expectation that the target stylesheet will be 977 applied by the HTML user agent. When associated with an A 978 element, an HTML user agent may simply retrieve the target 979 stylesheet for display, or it may launch a stylesheet editor 980 with the target stylesheet. 982 When REV=STYLESHEET, the current document is a stylesheet and 983 the target document may be a demonstration of its use. In 984 general, it is not anticipated that stylesheets will contain 985 LINK or A elements, as they are not projected to be HTML 986 documents. 988 TRANSLATION 989 The TRANSLATION relationship specifies a translation to 990 another language. 992 When REL=TRANSLATION, the target is a translation to another 993 language. This value will most typically be used with the LINK 994 element, in combination with specification of the target 995 document's language as a LANG attribute value. Presumably, 996 REL=TRANSLATION can be used with the A element to specify a 997 translation of a document fragment, such as a phrase in a 998 foreign language. 1000 When REV=TRANSLATION, the current document, or document 1001 fragment, is a translation of the target. 1003 URC 1004 The URC relationship identifies a Uniform Resource Catalogue 1005 for the current document. 1007 This keyword has been proposed by Dave Raggett. Its meaning 1008 and purpose have not been explained to the author, but a 1009 placeholder is being maintained until such time as Dave has had 1010 an opportunity provide explanation, examples, 1011 discussion and justification. 1013 5. Hypertext Includes 1014 There have been many discussions in various forums which clearly 1015 indicate that hypertext includes are a desired feature of the HTML 1016 language, and for which widespread user agent support is needed. 1018 There are, apparently, three popular syntactic approaches to 1019 inclusion: specifying INCLUDE as REL value on the A and LINK 1020 elements, specifying a newly-defined and specially- purposed INCLUDE 1021 element (which would presumably also have REL and REV attributes), 1022 and using SGML entities. Each is described and discussed below, but 1023 no arguments are presented. 1025 In either case, there is an expectation that processing of an 1026 INCLUDE link would result in the INCLUDE value being deleted from the 1027 REL list and inserted into the REV list. In other words, a 1028 REL=INCLUDE indicates that the inclusion has yet to happen, while a 1029 REV=INCLUDE indicates that the inclusion has already happened. It is 1030 helpful, for legal and copyright purposes, that included material be 1031 identifiable at all times. 1033 Note that the form of inclusion referred to here is also known as 1034 Transclusion, or as client side inclusion. It may happen either 1035 automatically, when a document is loaded into an HTML client, 1036 or explicitly: for example when the user selects an icon, included 1037 text may appear at that point in the current document. 1039 5a. INCLUDE as a REL or REV Value 1040 INCLUDE relationship identifies a document for inclusion. 1042 When REL=INCLUDE, the target document should be included at the 1043 anchor location. This value is typically, though not always, used 1044 with the A element. Using this value on a LINK element implies 1045 that the included document only contains information which is 1046 valid within the HEAD of an HTML document. 1048 When REV=INCLUDE, the current document is identifying itself as an 1049 included document in the target document. 1051 5b. INCLUDE as an Element 1052 An anchor may also be specified using a newly-defined INCLUDE 1053 element: 1054