Fragment Identifiers for Plain Text Files Erik Wilde and Marcel Baschnagel Computer Engineering and Networks Laboratory (TIK) Swiss Federal Institute of Technology (ETH Zurich)¨ [email protected] ABSTRACT Fragment identifiers have been defined for other widely Hypermedia systems like the Web heavily depend on their used resource types, such as XML (where fragment iden- ability to link resources. One of the key features of the tifiers are XPointers [4]) and PDF (where it is possible to Web’s URIs is their ability to not only specify a resource, identify pages and other subresources). However, since tool but to also identify a subresource within that resource, by support for working with URIs with fragment identifiers is using a fragment identifier. Fragment identification enables weak, and fragment identifiers often are less robust then ref- user to create better hypermedia. We present a proposal erences to the resource only, only a small fraction of links for fragment identifiers for plain text files, which makes it on the Web specify fragment identifiers. possible to identify character or line ranges, or subresources As a proof of concept, a prototypical implementation for identified by regular expressions. Using these fragment iden- plain text fragment identifiers has been developed, and there- tifiers, it is possible to create more specific hyperlinks, by fore it is possible to test and use these fragment identifiers not only linking to a complete plain text resource, but only in a server-based scenario as well as in the form of a Firefox the relevant part of it. Along with this proposal, a proto- extension. type implementation is described which can be used both as a server-side testbed and as a client-side extension for the 2. Plain Text Files and Hypertext Firefox browser. In terms of hypertext, plain text files have severe lim- Categories and Subject Descriptors: I.7.2 [Document itations, because they cannot contain outgoing links, and and Text Processing]: Document Preparation — Hy- they cannot serve as targets for links to subresources. Inter- pertext/Hypermedia; H.5.4 [Information Interfaces and estingly, defining fragment identifiers solves both problems, Presentation]: Hypertext/Hypermedia — Navigation because outgoing links can then be defined by using exter- 1 General Terms: Design, Standardization nal links (for example XLinks [3] ), and incoming links can point to subresources of the plain text file. Keywords: Plain Text, URI, XLink, Firefox The majority of files used on the Web are media types other than plain text, but there still is a large number of 1. Introduction plain text files available. These are either legacy files, which The Web heavily depends on its ability to link resources. were never converted to a richer media type (a non-trivial Even though the vast majority of links on the Web is us- task, if structure needs to be added), or they are output ing references to complete documents, the ability to refer- files from tools or systems which have plain text output, a ence document fragments greatly enhances the power of a popular example is the Comma-Separated Values (CSV) for- hypermedia system, and its usefulness for the users. The mat (a weakly structured format, but in terms of hypertext generic URI syntax [1] specifies fragment identifiers, and usage simply treated as unstructured plain text). For all thus enables Web links to point to document fragments. On these plain text resources, fragment identification makes it the Web, fragment identification depends on a resource’s possible to integrate them better into the hypermedia world MIME type, and the most popular fragment identification of the Web, even if only with incoming links. method is that of HTML. URIs with fragment identifiers In a Web with plain text fragment identification, it would such as http://www.w3.org/TR/html/#C_8 reference a par- for example be possible to have a link pointing to a partic- ticular subresource within the resource, in case of HTML ular line in a log file and thus be able to make a statement fragment identifiers the element with the id attribute set to about this subresource, such as the comment that this log C 8 (for example the anchor element <a id="C 8">...</a>). entry requires further investigation. 3. Fragment Identifiers for Plain Text Files Permission to make digital or hard copies of all or part of this work for Fragment identifiers are strings appended to a URI, us- personal or classroom use is granted without fee provided that copies are ing the # character as a separation between the resource not made or distributed for profit or commercial advantage and that copies identification and the fragment identifier. The generic URI bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific 1As pointed out by Bry and Eckstein [2], however, even after 4 permission and/or a fee. years the XLink specification has not had any success as a Web HT’05, September 6–9, 2005, Salzburg, Austria. technology. Copyright 2005 ACM 1-59593-168-6/05/0009 ...$5.00. syntax [1] states that “the fragment identifier component of a disjoint subresource (if there is more than one occurrence a URI allows indirect identification of a secondary resource of the case-insensitive string “RFC” within the resource). by reference to a primary resource and additional identify- ing information. [...] The fragment’s format and resolution 4. Implementation is [...] dependent on the media type of a potentially re- trieved representation, even though such a retrieval is only Implementations of the fragment identification scheme for performed if the URI is dereferenced.” plain text resources should be included in future Web brows- In an Internet Draft [6] currently under development (and ers, and in other tools handling plain text files (such as text open for discussion on the relevant mailing lists), a fragment viewers and editors), so that these tools can generate frag- identifier syntax and semantics for plain text resources has ment identifiers for inclusion into Web resources. As a pro- been defined. The basic building blocks of these fragment totype, we have implemented fragment identifier interpreta- identifiers are the following: tion code that operates in three steps: • Positions and Ranges: Positions identify fragments of 1. Identifier Analysis: The fragment identifier is analyzed length zero, which may be a useful concept if a link ex- and it is tested whether it conforms to the syntax def- presses the concept of “insert some text here”. Ranges, inition. on the other hand, are fragments that span between 2. Resource Analysis: The resource is retrieved, tested two positions, and thus can be thought of what users for its MIME type, tested for its character encoding, normally can select with a mouse. and tested against the fragment identifier’s hash sum • Characters and Lines: The only plain text structures (if present). that can be identified reasonably across different char- 3. Identifier Application: If the fragment identifier is cor- acter encodings are individual characters and lines. rect and applicable, the subresource is located and pre- Both concept are important when dealing with plain sented to the user. text files, and are usually supported by text tools (for example providing a “go to line” function). Since a prototype should be available for as many inter- ested users as possible, it is available in two configurations, • Regular Expressions: While characters and lines easily as server-side and client-side implementation. break when the file is modified, it may be more robust to identify a subresource through string matching. By 4.1 Server-Side Implementation using a regular expression, a fragment identifier selects The server-side implementation is based on Perl, which all character ranges matching this regular expression. provides excellent string handling functionality and thus is The concepts of positions/ranges and characters/lines may ideally suited to support the interpretation of fragment iden- be combined to use line ranges and similar concepts. Also, tifiers. The server-side implementation is available for test- different identification methods can be combined, and the ing at http://dret.net/text-fragment/ and can be used fragment identified by such a combination is the union of all with any text file. individually identified fragments. As with regular expres- sions, this may easily lead to disjoint subresources, which is not a problem and can be easily represented by using high- lighting or similar concepts. Finally, a hash value can be used to be able to detect changes in the resource. This may be useful to be able to detect potentially broken fragment identifiers. As long as the hash value (with may be the length or the MD5 check- sum) has not changed, the resource probably has not been changed and the fragment identifier can safely be applied. The following examples show how the concepts are used in actual fragment identifiers. They are using some of the frag- ment identification schemes defined by the fragment identi- fier syntax. Both examples assume that the resource re- trieved by dereferencing the URI is a plain text file. 1. http://example.com/text.txt#line=10,20 2. http://example.com/text.txt#match=[rR][fF][cC] In the first example, the URI identifies a fragment consist- Figure 1: Demo Text with Fragment Identifier ing of lines 11–20 of the identified resource. If the resource does not have that many lines, the fragment is smaller or A simple example is shown in Figure 1, which is the re- may even be empty. The URI of the second example2 iden- sult of applying a three-part fragment identifier to a text tifies a fragment of the resource which consists of a case- file containing this paper’s abstract.