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 ... 208 A specialized active hypertext link anchor known as an image map 209 may be specified by using the IMG element in combination with the 210 SRC and ISMAP attributes. An example of this form of IMG usage 211 is: 212 214 2b. Targets 215 A target is any addressable object or resource which typically 216 serves as the destination of a hypertext link. The destination 217 may be another HTML document, a fragment within the same or 218 another HTML document, or any other type of object or resource. 220 A target may also be an aggregate link which can be presented as 221 a list of possible targets from which a user can select. A Table 222 of Contents may be an example of an aggregate link. The result of 223 a query is an other example. 225 Any addressable object may serve as the target of a hypertext 226 link. Typically, a target is addressed by specifying a URL/URI as 227 the value of an HREF or SRC attribute on HTML elements which 228 support those attributes. 230 HTML also provides a number of language elements which may be 231 used to identify a target within an HTML document and to specify 232 the base location from which relative addresses should be 233 formed. 235 There are four ways to specify a target within an HTML document: 236 * the BASE element 237 * the NAME attribute of the A element 238 * the ID attribute of various elements, including A and LINK 239 (HTML 3.0 proposal) 240 * the NAME attribute of the LINK element 242 The base location of a document may be recorded in the BASE 243 element in the HEAD of the document. The base location is the 244 address from which all relative URL addresses are to be formed. 245 For example: 246 248 A target may be specified by surrounding any object (word, 249 phrase, graphic image, etc.) with an A element having a non-null 250 NAME attribute, and the target is considered to be the beginning 251 of the encapsulated object. For example: 252 target object 254 A target may also be specified by providing a value for the ID 255 attribute on any HTML element which supports that attribute. 256 For example: 257

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 1056 In this scheme, when the hypertext link is traversed, and the 1057 content of the target document is included, the INCLUDE element 1058 would surround the included text. As a function of traversing the 1059 link, the REL attribute value would be transformed to a REV value, 1060 thus maintaining information about the link. 1061 1062 This is the boilerplate text 1063 1065 5c. SGML external entitities 1066 SGML provides a mechanism for specifying external entities and 1067 including them, by reference, in an SGML document. 1069 Unfortunately, the current HTML browser technology cannot easily 1070 support the use of SGML entities, and they cannot be used in 1071 a way that is completely backwards-compatible with existing 1072 software. 1074 6. Hypertext Paths 1075 NOTE: Recent discussions tend to indicate that the mechanisms and 1076 language uses needed to support paths have not been adequately 1077 articulated or specified. This section appears here for historical 1078 completeness. Dave Raggett's further explanation and justification is 1079 needed before any further discussion or decision can be made as to 1080 the future status of these keywords. 1082 Paths are described briefly in Dave Raggett's Internet Draft on HTML 1083 3.0, and reproduced below without further explanation. Further 1084 discussion, explanation and justification from Dave are clearly 1085 required before any further public discussion or decision can be 1086 made as to the future status of these keywords. The material below 1087 is reproduced for historic purposes and may be subject to future 1088 revision. 1090 Values for use in defining Guided Tours with element. These 1091 allow Guided Tours to be defined using HTML, for instance as part of 1092 tables of contents, for example: 1093 1095 NODE 1096 The NODE relationship implies PREVIOUS/NEXT LINKs for given URI. 1098 PATH 1099 The PATH relationship specifies that the given URI contains links that should be inserted into the guided tour. 1102 The browser treats the REL=NODE URIs as forming a sequence of 1103 nodes to follow and sets the , NEXT as 1104 appropriate for each node as it is visited. 1106 7. Proposed New Attributes for A and LINK Elements 1108 Through the course of discussions, suggestions have been made to 1109 create new attributes for the LINK and/or A elements. These are 1110 preliminary discussions, with no sample implementations to 1111 demonstrate support. 1113 7a. ACTION or STYLE or PROCESS or PRESENT 1114 Activating a link in the HTML user agents of mid-1995 typically 1115 results in the linked object replacing the current object in the 1116 presentation window of the user agent. By convention, HTML user 1117 agents typically provide an alternate method which spawns another 1118 window and presents the linked object in it. 1120 It has been suggested by Ian Graham and Roy Fielding, and agreed 1121 upon by many others, that the author should have some means to 1122 indicate a preference for the manner in which the user agent 1123 should present the linked object to the user. As you can see, the 1124 name of the attribute still needs to be settled. 1126 From Ian Graham: It seems reasonable to allow the 1127 author to suggest browser behavior when links are activated. 1128 For example, when I click on a LINK button, should I clone a 1129 window for the link, or pop up a subwindow for a glossary 1130 entry? Perhaps this should be part of a CLASS attribute, but 1131 to my mind CLASS should be used to define the 1132 presentation/meaning of a document element in the document BODY 1133 as opposed to browser behavior. 1135 And from Roy Fielding: Presentation semantics -- where should 1136 the results be "placed". A `STYLE=""' attribute (defined as 1137 SGML NAMES) would do nicely here. 1139 Possible values and their meanings are: 1140 CLONE 1141 Present the linked object in a presentation window which is a 1142 clone of the current presentation window. That is popup another 1143 persistent window. 1145 See the Netscape Frames proposal for one way to do this, using 1146 named windows and the TARGET attribute described below. 1148 EMBED 1149 Present the linked object at the current location. This 1150 provides a syntax for expressing "stretch text", but it also 1151 presents numerous problems. This will be subject to much 1152 debate. See the section on Include, above. 1154 REPLACE 1155 The default behavior. Present the linked object in the current 1156 presentation window, replacing the current object completely. 1158 POPUP 1159 Present the linked object in a non-persistent presentation 1160 window. That is, show the linked object while the user is 1161 activating the link, and make it disappear when the user 1162 releases activation. In the case that the popup is entered 1163 without user activation, the user agent may provide a "Cancel" 1164 button or another mechanism to make the popup window 1165 disappear. 1167 SPLITSCREEN or HORSPLIT 1168 Present the linked object in one pane of a horizontally split 1169 window. 1171 ALONGSIDE or VERSPLIT 1172 Present the linked object in one pane of a vertically split 1173 window. 1175 7b. TARGET 1176 Netscape Corporation have proposed to add a TARGET attribute to 1177 the A element; its value is the name of the window in which to 1178 display the result of following the link. 1180 This is most useful in conjunction with a mechanism (such as 1181 FRAMES, not discussed in this document) to give names to windows. 1182 However, if no window exists with the given name, a reasonable 1183 action is to create such a window. 1185 An HTML client in a non-windowing environment would have to find 1186 some way to indicate the presence of multuple active document areas, 1187 and to allow navigation amongst them. 1189 7c. DINGBAT 1190 The DINGBAT attribute, applied to the LINK element and the A 1191 element, would be used to specify the entity name of a graphic 1192 image (an icon) to associate with a hypertext link. The DINGBAT 1193 attribute values must be specified by the HTML DTD as an SGML name 1194 token group. 1196 When used with LINK, the icon may be used on an HTML user agent 1197 toolbar. When used with A, the icon may be placed in close 1198 proximity to the anchor's highlighted text, as a footnote marker 1199 for example. 1201 There are advantages to using an entity rather than an external 1202 graphic. Presumably, a user agent would pre-load the standard set 1203 of entities, thereby eliminating the need to fetch a graphic 1204 across the network. It is hoped that user agents will provide 1205 users with a means to specify the system location of personalized 1206 or customized versions of standard icons, thereby offering the 1207 user the opportunity to exercise greater control over the user 1208 interface and the graphical presentation. 1210 The DINGBAT attribute has already been proposed for lists and list 1211 items in Dave Raggett's Internet Draft on HTML 3.0. User agent 1212 behavior, in the face of contention between DINGBAT and SRC, must 1213 be specified. 1215 7d. HILITE or HIGHLIGHT 1216 Roy Fielding has pointed out that the author can 1217 indicate a preference for the style of anchor 1218 highlighting. So far, the list of candidate 1219 keywords are: 1220 * None 1221 * Button 1222 * IconOnly 1223 * Underline 1224 * Outline 1225 * Reverse 1227 7e. METHOD 1228 From Ian Graham: It would often be convenient to 1229 access a link using a defined HTTP method other than GET. For 1230 example, suppose I have a LINK attribute defining a related, 1231 searchable glossary. One desirable behavior is as follows: the 1232 user highlights a word and clicks a mouse button (or presses a 1233 glossary button). The browser accesses the linked object, passing 1234 to it the highlighted text. The server then returns the glossary 1235 entry relevant to the highlighted word. This requires 1236 standardised methods and data encoding schemes. There is only one, 1237 namely the HTTP TEXTSEARCH method, which is how ISINDEX search 1238 queries are sent to a server. I therefore propose that the METHOD 1239 attribute have two possible values, namely GET|TEXTSEARCH, to 1240 indicate how the client should access the linked resource. 1242 7f. SRC 1243 The SRC attribute, applied to the LINK element and the A element, 1244 would be used to specify the location of a file containing a 1245 graphic image (an icon) to associate with a hypertext link. When 1246 used with LINK, the icon may be used on an HTML user agent 1247 toolbar. When used with A, the icon may be placed in close 1248 proximity to the anchor's highlighted text, as in the case of a 1249 footnote marker for example. 1251 This extension of the applicability of the SRC attribute has 1252 already been proposed for lists, list items, and admonishments in 1253 Dave Raggett's Internet Draft on HTML 3.0. User agent behavior 1254 remains to be specified in the face of contention between DINGBAT 1255 and SRC attributes. 1257 7g. WHEN 1258 Roy Fielding and Ian Graham have pointed out that user agents 1259 currently exhibit different behavior between their processing of 1260 hypertext links specified with the SRC attribute and those 1261 specifiewd with HREF. Typically, user agents await user activation 1262 before traversing a hypertext link specified with an HREF 1263 attribute, while those specified with SRC are more often fetched 1264 immediately. This distinction is a natural consequence of a 1265 design which uses the SRC attribute to specify a hypertext link to 1266 an embedded graphical image. 1268 The author can take advantage of an ability to specify when, or 1269 the type of event, which should initiate the hypertext link. 1271 Roy Fielding suggested the following possible attribute values: 1272 UserSelect as is the case for anchors and FORMS 1273 AutoEntry as is the case for EMBED or IMG 1274 AutoExit an interesting derivative 1275 Export only used external to the user process 1276 In response, Murray Maloney asked: Would the AutoExit derivative 1277 provide a means for me to do indirection? For example, in 1278 document A I have , and in B I have . Would asserting the anchor in A lead me 1280 to C? If so, wonderful. If not, then why not and what then? 1282 Please explain the meaning of "Export"? That is, if I use it what 1283 does it imply about "when should the action take place"? 1285 (Liam Quin things Export doesn't imply any action at all, but 1286 doesn't yet understand why it might be useful) 1288 Consider these examples: 1289 1291 1293 Copyright 1995 by Murray C. Maloney 1294 In either case, the user agent is expected to display the target 1295 document in a popup as soon as the current document is retrieved. 1297 7h. OBSOLETES, UPDATES and DERIVED-FROM: 1298 Roy Fielding also suggested the following relations: 1299 OBSOLETES 1300 when REL=OBSOLETES, the target document is a later version of 1301 the current document; when REV=OBSOLETES, the target document 1302 is obsoleted by the current document. 1304 UPDATES 1305 When REL=UPDATES, the target document contains revisions to the 1306 current document (would REVISES be clearer?). 1308 DERIVED-FROM 1309 When REL=DERIVED-FROM, the target document was derived from the 1310 current document; when REV=DERIVED-FROM, the current document 1311 was derived from the target document, perhaps by automatic 1312 processing or by manual editing. 1314 8. Acknowledgements 1315 This paper is the synthesis and codification of ideas from 1316 a variety of sources. It is only fitting that those who 1317 have contributed to the discussion in various forums should 1318 be acknowledged for their part in the recent attempt to 1319 move this work forward. 1320 Terry Allen, O'Reilly and Associates, terry@ora.com 1321 Murray M. Altheim, NTTC, murray.altheim@nttc.edu 1322 Brian Behlendorf, Indiana Univ., brian@organic.com 1323 Bert Bos, Rijksuniversiteit Groningen, bert@let.rug.nl 1324 Jon Bosak, Novell, Jon Bosak@novell.com 1325 Henry Budgett, SCO, henryb@sco.com 1326 Paul Burchard, burchard@geom.umn.edu 1327 Dan Connolly, MIT/W3C, connolly@w3.org 1328 Steve DeRose, Electronic Book Technologies, steve@ebt.com 1329 Joe English, joe@trystero.art.com 1330 Roy T. Fielding, Univ. of California (Irvine), fielding@ics.uci.edu 1331 Peter Flynn, pflynn@curia.ucc.ie 1332 Ian Graham, Univ. of Toronto, igraham@utirc.utoronto.ca 1333 Dave Hollander, HP, dmh@hpsgml.fc.hp.com 1334 Alex Hopmann, ResNova Software, Inc., hopmann@holonet.net 1335 Craig Hubley, Craig Hubley & Associates, craig@passport.ca 1336 Albert Lunde, Albert-Lunde@nwu.edu 1337 Tom Magliery, NCSA, mag@ncsa.uiuc.edu 1338 Eve Maler, ArborText, eve@doctools.com 1339 Larry Masinter, Xerox, masinter@parc.xerox.com 1340 Eric Miller, OCLC, emiller@oclc.org 1341 Lou Montulli, Netscape Communications, montulli@netscape.com 1342 David Morris, dwm@shell.portal.com 1343 Dave Raggett, MIT/W3C, dsr@w3.org 1344 Bob Stayton, SCO, bobs@sco.com 1345 Stu Weibel, OCLC, weibel@oclc.org 1346 Faith Zack, SCO, faithz@sco.com