idnits 2.17.1 draft-pam-html-fine-trans-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 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 -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([MERGE], [RFC1866]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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.) -- The document date (2 March 1997) is 9916 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'MERGE' ** Obsolete normative reference: RFC 1866 (Obsoleted by RFC 2854) Summary: 11 errors (**), 0 flaws (~~), 1 warning (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET DRAFT Andrew Pam 2 Project Xanadu 3 Expires 2 September 1997 2 March 1997 5 Fine-Grained Transclusion in the Hypertext Markup Language 7 Status of this Memo 9 This document is an Internet-Draft. Internet-Drafts are working doc- 10 uments of the Internet Engineering Task Force (IETF), its areas, and 11 its working groups. Note that other groups may also distribute work- 12 ing documents as Internet-Drafts. 14 Internet-Drafts are draft documents valid for a maximum of six 15 months. Internet-Drafts may be updated, replaced, or obsoleted by 16 other documents at any time. It is not appropriate to use Internet- 17 Drafts as reference material or to cite them other than as a "working 18 draft" or "work in progress". 20 To learn the current status of any Internet-Draft, please check the 21 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 22 Directories on ds.internic.net (US East Coast), nic.nordu.net 23 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 24 Rim). 26 Distribution of this document is unlimited. Please send comments 27 to the author at . This document is intended to 28 become an informational RFC, and its content is designed for adoption 29 in other standards and specifications. 31 Abstract 33 The word "hypertext" was coined by Theodor Holm Nelson in his paper 34 "A File Structure for the Complex, the Changing and the 35 Indeterminate", presented at the ACM 20th national conference in 36 1965. One of the key concepts in Nelson's vision of hypertext is 37 "transclusion" or virtual inclusion, which permits composite 38 documents to be constructed by reference to the original components 39 rather than by copying. 41 The Hypertext Markup Language (HTML) is a markup language used 42 to create hypertext documents that are platform independent. 43 HTML currently permits the transclusion of various content types 44 using tags which accept a "SRC" attribute, such as the , 45 and tags, but does not provide a mechanism for transcluding 46 textual content. This document proposes markup for text 47 transclusions in HTML and explains its usage. 49 Introduction 51 The Hypertext Markup Language (HTML) [RFC1866] is a simple markup 52 language used to create hypertext documents that are platform 53 independent. This draft describes markup for an additional feature 54 needed to support Nelson's vision of composite documents constructed 55 by reference to the original documents. For more information, see 56 http://www.xanadu.net/xanadu/ 58 Syntax 60 The proposal is to add an HTML tag with the following syntax: 62 64 Where parentheses () enclose variable parameters and braces {} 65 enclose optional elements. 67 The SRC attribute is mandatory, and specifies the source document 68 from which text is to be transcluded. (URI) must be the Universal 69 Resource Identifier of a plain text or HTML document. If the source 70 document is HTML and the optional PLAIN attribute is specified, 71 all HTML tags are removed and all SGML entities converted to the 72 characters they represent. If PLAIN is omitted, the source document 73 is transcluded verbatim. In either case, only the contents of the 74 element of the source document is transcluded. If the source 75 document is already plain text, the PLAIN attribute has no effect. 77 If the optional RANGE attribute is specified, only part of the 78 source document is transcluded. (start) and (end) are integers 79 representing character offsets from the beginning of the source 80 document (immediately after the tag for HTML) or negative 81 character offsets from the end of the source document (immediately 82 before the tag for HTML). If (end) is zero, the source 83 document is transcluded until the end. 85 Implementation 87 The intention is to have a facility in authoring programs that 88 permits the author to create transclusions by indicating an insertion 89 point, viewing the document from which they wish to transclude, 90 and marking the region to be transcluded, much in the manner of a 91 traditional "cut and paste" operation except that what is actually 92 pasted is the reference to the transcluded portion rather than the 93 literal text. 95 Initially, this could be a small editing program purely for adding 96 transclusions to existing documents. It has also been suggested that 97 people might wish to add transclusions by hand, in which case it 98 might be desirable to have other ways of specifying the start and end 99 of the range besides just the byte offsets, which are inconvenient 100 to determine by hand. 102 Possible Extensions 104 The following additional formats have been proposed for the (start) 105 and (end) values: 107 1. HTML target anchors within the source 108 document, indicated by a hash character followed by the anchor 109 name. These can optionally be followed by a positive or negative 110 character offset from immediately before the tag, for example 111 "RANGE=#start+5,#end-1". 113 2. Paragraphs within the source document, indicated by the letter P 114 and the paragraph number counting from the beginning of the 115 document. These can optionally be followed by a positive or 116 negative character offset from the start of the paragraph, for 117 example "RANGE=P5+2,P9-3". A paragraph break is represented 118 by one or more blank lines in a plain text document and the

119 tag in an HTML document. 121 3. Pattern matches within the source document, indicated by slashes 122 or single or double quotes delimiting the pattern to match and 123 optionally the letter I indicating a case insignificant match. 124 Pattern matches were suggested by Paul Haeberli in his "Merge" 125 script [MERGE]. These can optionally be followed by a positive or 126 negative character offset from the start of the match, for example 127 "RANGE=/

/i+3,'
'i-5". Only the first match is 128 used, and the transclusion is not performed at all if a match 129 can not be found in the source document. 131 Acknowledgements 133 Paul Haeberli 134 Theodor Holm Nelson 135 Yousuke Igarashi 137 References 139 [MERGE] http://reality.sgi.com/grafica/merge/ 141 [RFC1866] T. Berners-Lee and D. Connolly, "Hypertext Markup Lan- 142 guage - 2.0" (RFC1866), MIT/W3C, November 1995. 144 Author's Address 146 Andrew Pam 147 Project Xanadu 148 P.O. Box 26 East Melbourne VIC 8002 Australia 150 Phone: +61 3 9651 1511 151 Fax: +61 3 9651 1502 152 Email: xanni@xanadu.net