Fragment.html
9 KB
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta name="generator" content=
"HTML Tidy for Mac OS X (vers 31 October 2006 - Apple Inc. build 13), see www.w3.org" />
<title>
Fragment Identifiers -- Axioms of Web architecture
</title>
<link href="di.css" rel="stylesheet" type="text/css" />
<meta http-equiv="Content-Type" content=
"text/html; charset=us-ascii" />
</head>
<body bgcolor="#DDFFDD" text="#000000">
<address>
Tim Berners-Lee
<p>
Date: April, 1997
</p>
<p>
Status: personal view, but believed to be my best
expression of the underlying architecture for W3C
development. Editing status: Good enough fo discussion.
</p>
</address>
<p>
<a href="Overview.html">Up to Design Issues</a>
</p>
<h3>
Axioms of Web Architecture
</h3>
<hr />
<h1>
URI References: Fragment Identifiers on URIs
</h1>
<p>
The URI by itself is a powerful thing, but there is a more
powerful concept which is the URI reference.
</p>
<p>
The URI reference is a thing you build by taking a URI for an
information object, adding a "#" sign and then a
<strong>Fragement identifier</strong>. (The last term is
historical, so try not to thinl of it necessarily identifying
a fragment).
</p>
<p>
The fragment identifier is a string after URI, after the
hash, which identifies something specific as a function of
the document. For a user interface Web document such as HTML
poage, it typically identifies a part or view. For example in
the object
</p>
<pre>
http://foo/bar#frag
</pre>
<p>
the string "frag" is the fragment identifier. It is badly
named, as it can identify anything.
</p>
<p>
(Depending on where you look, the URI is considered to
include the fragment identifier, or to have the fragment
identifier appended to it. This is important for the
BNF, but in practice you will find people using the terms URI
and URL loosely to things which do or do not include a
possible fragment identifier. Formally, the URI
<strong>does</strong> include the fragment ID)
</p>
<p>
In practice, you can divide the processing which occurs when
following a link using HTTP into three steps:
</p>
<ol>
<li>The client figures out which server to contact by parsing
part of the URL, and sends the URL as a request to the
server;
</li>
<li>The server figures out which object is referred to by
parsing the rest of the URL, and returns some rendition of it
to the client;
</li>
<li>The client presents all or part of the object to the user
</li>
</ol>
<p>
The last part typically involves finding some software class
which can handle the given MIME type, and passing it the data
stream. At the same time, the fragment identifier is
passed as a parameter to the created object.
</p>
<p>
For HTML, the fragment ID is an SGML ID of an element within
the HTML object. For XML, if it is just a word, then it is
the XML ID of an element in the document.
</p>
<h4>
<a name="significance" id="significance">Axiom</a>
</h4>
<p class="axiom">
The significance of the fragment identifier is a function of
the MIME type of the object
</p>
<p>
This means that the fragment id is opaque for the rest of the
client code. The HTTP engine cannot make any
assumptions about it. The server is not even given it.
</p>
<p>
It also means that for any new data type one can be creative
about using the fragment ID in a relevant way. For example,
for a 3D object the fragment ID could give a
viewport. For a music object, the Fragment ID could give a
section in time, or a set of parts, or it could include
a suggested tempo. For future versions of HTML, the
fragment ID could be made more powerful to include a range or
"ladder" reference to a part or parts of the SGML element
tree by position. A very useful fragment ID for plain text
would allow ranges to be quoted by line and character number
</p>
<p>
These things are all decisions made when the MIME type is
defined. Therefore,
</p>
<p class="axiom">
The fragment ID spec for a new MIME
type should be part of the MIME type registration
process.
</p>
<p>
Different MIME types then can have different fragment ID
specifications. When HTTP for example negotiates between
different content types, it is clearly useful for those types
to have a consistent (hopefully identical) fragment ID syntax
and semantics.
</p>
<h3 id="Fragment1">
<a name="Fragment2" id="Fragment2">Fragment identifiers for
RDF identify concepts</a>
</h3>
<p>
The semantic web has information about anything. The fragment
identifier on an RDF (or N3) document identifies not a part
of the document, but whatever thing, abstract or concrete,
animate or innanimate, the document describes as having that
identifier.
</p>
<p>
It is important, on the Semantic Web, to be clear about what
is identified. An <code>http:</code> URI (without fragment
identifier) necessarily identifies a <a href=
"Generic.html">generic document</a>. This is because the HTTP
server response about a URI can deleiver a rendition of (or
location of, or apologies for) a document which is identified
by the URI requested. A client which understands the http:
protocol can immediately conclude that the fragementid-less
URI is a generic document. This is true even if the publisher
(owner of the DNS name) has decided not to run a server. Even
if it just records the fact that the document is not
available online, still a client knows it refers to a
document. This means that identifiers for arbitrary RDF
concepts should have fragment identifiers. This, in turn,
means that RDF namespaces should end with "#".
</p>
<h3 id="Object">
Object Names as fragment identifiers
</h3>
<p>
When a document language (MIME type) has some form of
intra-document naming for objects then it is intuitive is
these names can be directly used as fragment identifiers.
This is true for XML, that the XML ID which is used to
identify elements can be directly used as a fragment
identifier.
</p>
<h3>
<a name="Fragment" id="Fragment">Fragment IDs and Content
negotiation - known bug</a>
</h3>
<p>
If content negotiation occurs across types which do NOT share
a fragment ID specification, then rigidly there has been an
error. In practice, HTML was the only type (in 1997) which
allowed fragment IDs anyway, and other types ignore it. Also,
as falling back from a pointer to a specific view to a
pointer to the whole document has been considered effective
fallback procedure, so no harm was done. Now (2001) it
becomes more of a problem. there have been proposasl to add
the requested fragment idntifier to the HTTP request to fix
this.)
</p>
<p>
In the future, metadata returned or warnings returned should
indicate to the client that this could be a problem. Also, in
new access protocols, the fragment ID requested could be
shipped to the server as a hint, which would allow the server
and client to negotiate and if successful arrange for the
fragment ID to be converted to a suitable equivalent value
for an alternative MIME type.
</p>
<h3>
<a name="User" id="User">User awareness of the form of a
reference</a>
</h3>
<p>
Clearly when a fragment ID is generated and associated with a
URI which is generic in any way (language, version, etc as
well as content-type), then there is a possible failure of
the fragment-id refers to something which is not defined in
any specific instance. It would be appropriate for a
client, when generating a link (or bookmark, etc) to provide
the user with a choice of
</p>
<ul>
<li>A bookmark to the whole living document, or
</li>
<li>A bookmark to a specific part of a "dead" version;
</li>
<li>Intermediate combinations.<br />
</li>
</ul>
<p>
As both these options are meaningful and useful, they will
have to surface at the user interface level.
</p>
<hr />
<p>
<a href="Axioms.html">Back to URIs</a> --- <a href=
"LinkLaw.html">Next: Links and the law</a>
</p>
<p>
<a href="Overview.html">Up to Design Issues</a>
</p>
<p>
<i><small>$Id: Fragment.html,v 1.6 1998/03/04 17:24:58 timbl
Exp $</small></i>
</p>
</body>
</html>