NOTE-xlink-principles-19980303
12 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
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
<!doctype html public '-//W3C//DTD HTML 4.0 Transitional//EN' 'http://www.w3.org/TR/REC-html40-971218/loose.dtd'><HTML><HEAD><meta name='GENERATOR' content='XML/XH/Lark'><TITLE>XML Linking Language (XLink) Design Principles</TITLE></HEAD><BODY BGCOLOR='#ffffff'>
<H3 align='right'><A HREF='http://www.w3.org/'><IMG border='0' align='left' alt='W3C' src='http://www.w3.org/Icons/WWW/w3c_home'></A>NOTE-xlink-principles-19980303</H3><br><H1 align='center'>XML Linking Language (XLink) Design Principles</H1>
<h3 align='center'>World Wide Web Consortium Note
3-March-1998 </h3>
<DL><DT>This version:</DT><dd><A HREF='http://www.w3.org/TR/1998/NOTE-xlink-principles-19980303'>http://www.w3.org/TR/1998/NOTE-xlink-principles-19980303</A>
<DT>Latest version:</DT><dd><A HREF='http://www.w3.org/TR/NOTE-xlink-principles'>http://www.w3.org/TR/NOTE-xlink-principles</A></DL>
<DL>
<dt>Editors:</dt>
<DD>Eve Maler (ArborText) <A HREF='mailto:
elm@arbortext.com'><elm@arbortext.com></A></DD>
<DD>Steve DeRose (Inso Corp. and Brown University
) <A HREF='mailto:sderose@eps.inso.com'><sderose@eps.inso.com></A>
</DD>
</DL>
<h2>Status of this document</h2>
<P>This is a W3C Note for use by W3C members and other parties interested
in using and implementing the XML Linking Language (XLink) and its related
XML Pointer Language (XPointer). It reflects the consensus of the XML Working
Group. This document may be updated, replaced, or obsoleted by other documents
at any time, though it is expected to remain fairly stable.</P>
<P>The design principles described herein have been thoroughly reviewed,
and are in part based on the principles that informed the design of XML. Thus,
while comments are welcome and will be given due consideration, the principles
are likely to be changed only after a very persuasive case is made, so that
the design of XLink can proceed apace. Please send any comments to the editors
of this Note.</P>
<P>For current status of the XML Activity, see <A HREF='http://www.w3.org/MarkUp/SGML/Activity'>
http://www.w3.org/MarkUp/XML/Activity</A>).</P>
<H2>Abstract</H2>
<P>This document explicates the design principles behind the XLink language
and its related XPointer language.</P>
<H1>XML Linking Language (XLink) Design Principles</H1><H1>Version 1.0</H1><h2>Table of Contents</h2>1. <A HREF='#1'>XLink Design Principles</A><BR>
1.1 <A HREF='#1.1'>XLink Shall Be Straightforwardly Usable Over the Internet</A><BR>
1.2 <A HREF='#1.2'>XLink Shall Be Usable by a Wide Variety of Link Usage Domains and of
Classes of Linking Application Software</A><BR>
1.3 <A HREF='#1.3'>The XLink Expression Language Shall Be XML</A><BR>
1.4 <A HREF='#1.4'>The XLink Design Shall Be Prepared Quickly</A><BR>
1.5 <A HREF='#1.5'>The XLink Design Shall Be Formal and Concise</A><BR>
1.6 <A HREF='#1.6'>XLinks Shall Be Human-Readable</A><BR>
1.7 <A HREF='#1.7'>XLinks May Reside Outside the Documents in Which the Participating Resources
Reside</A><BR>
1.8 <A HREF='#1.8'>XLink Shall Represent the Abstract Structure and Significance of Links
</A><BR>
1.9 <A HREF='#1.9'>XLink Must Be Feasible to Implement</A><BR>
2. <A HREF='#2'>XPointer Design Principles</A><BR>
2.1 <A HREF='#2.1'>XPointers Shall Address into XML Documents</A><BR>
2.2 <A HREF='#2.2'>XPointers Shall Be Straightforwardly Usable Over the Internet</A><BR>
2.3 <A HREF='#2.3'>XPointers Shall Be Straightforwardly Usable in URIs</A><BR>
2.4 <A HREF='#2.4'>The XPointer Design Shall be Prepared Quickly</A><BR>
2.5 <A HREF='#2.5'>The XPointer Design Shall Be Formal and Concise</A><BR>
2.6 <A HREF='#2.6'>The XPointer Syntax Shall Be Reasonably Compact and Human Readable</A><BR>
2.7 <A HREF='#2.7'>XPointers Shall Be Usable</A><BR>
2.8 <A HREF='#2.8'>XPointers Must Be Feasible to Implement</A><BR>
3. <A HREF='#3'>References</A><BR>
<HR>
<H2><A NAME='1'>1. XLink Design Principles</a></h2>
<H3><A NAME='1.1'>1.1 XLink Shall Be Straightforwardly Usable Over the Internet</a></h3>
<P>This implies the following:<UL>
<LI>It is a requirement to allow for "open systems" of linking where
not all resources are under the control of a single person or organization
(along with easier "closed systems"). For example, broken links must be tolerated.
</LI>
<LI>Both unidirectional links (common on the Web today) and multidirectional
links (commonly used in commercial hypermedia systems) must be supported.
</LI>
<LI>Interoperability of linking application software is important.
</LI>
<LI>Internationalization is important.</LI>
</UL>
<H3><A NAME='1.2'>1.2 XLink Shall Be Usable by a Wide Variety of Link Usage Domains and of
Classes of Linking Application Software</a></h3>
<P>XLink should not favor particular domains over others. For example, it
should be usable in scholarly annotation, cross-referencing in technical publications,
and other domains of link usage.</P>
<P>In addition, XLink should not favor (for example) traditional browsers
over other kinds of application software, such as tree-walking navigational
devices or editing systems.</P>
<H3><A NAME='1.3'>1.3 The XLink Expression Language Shall Be XML</a></h3>
<P>XLink is an XML-based language; that is to say, individual XLink structures
must be represented using XML element and attribute markup.</P>
<H3><A NAME='1.4'>1.4 The XLink Design Shall Be Prepared Quickly</a></h3>
<P>As a critical component for the success of the XML family of specifications,
XLink must be developed as quickly as possible.</P>
<H3><A NAME='1.5'>1.5 The XLink Design Shall Be Formal and Concise</a></h3>
<P>In particular, XLink characteristics should be explained in a fashion that
does not confuse the link topology with the XML syntax used to express links.
Such characteristics might include the required number of participating resources
and inheritance of locator settings.</P>
<H3><A NAME='1.6'>1.6 XLinks Shall Be Human-Readable</a></h3>
<P>Although XLink structures may be compressed, encrypted, or otherwise put
into binary/unreadable form for transmission or internal processing, they
must be in clear-text form to be considered XLinks.</P>
<H3><A NAME='1.7'>1.7 XLinks May Reside Outside the Documents in Which the Participating Resources
Reside</a></h3>
<P>It is a requirement that XLink provide a means to do sophisticated out-of-line
linking, in order for it to offer scalability and relief from HTML linking
problems. This does not mean that all links must be out-of-line; on the contrary,
the "Straightforwardly Usable Over the Internet" principle demands that simple
in-line linking also be accounted for.</P>
<H3><A NAME='1.8'>1.8 XLink Shall Represent the Abstract Structure and Significance of Links
</a></h3>
<P>It is not a goal to provide the specification of precise link formatting
and behavior because we don't want to encourage procedural markup. However,
some small amount of "hinting" about basic link behavior is acceptable in
order to accommodate frequently required functionality, particularly in the
short term.</P>
<H3><A NAME='1.9'>1.9 XLink Must Be Feasible to Implement</a></h3>
<P>It is a nongoal for XLink to be <EM>easy</EM> to implement because
we recognize that certain functionality, in particular out-of-line link handling
with extended document groups, is inherently difficult. Our goal is to make
implementation at least tractable; that is, we must consider implementability
in our deliberations.</P>
<H2><A NAME='2'>2. XPointer Design Principles</a></h2>
<H3><A NAME='2.1'>2.1 XPointers Shall Address into XML Documents</a></h3>
<P>The XPointer language is for addressing into the structures of XML documents
for the purpose of hyperlinking. While the XPointer syntax may be used to
represent addressing into other well-defined structured data, its semantics
are defined in terms of XML structures, and the XPointer specification cannot
guarantee the interoperability of its use for other data types.</P>
<P>Further, because XPointer is intended to serve hyperlinking purposes, it
does not attempt to define a query language such as would be used for structure-aware
information retrieval on XML documents. There are some similarities because
links must refer to specific locations by characterizing them in some way.
However, with links the focus is on the desired locations, while with queries
the focus is on the specification itself. Because of this and other practical
differences, XPointer does not attempt to solve the many complex issues involved
in designing a full-fledged query language for structured and semi-structured
data (on which see, for example, <A href='#ijdla'>[IJDLa]</A> and <A href='#ijdlb'>[IJDLb]</A>).
</P>
<H3><A NAME='2.2'>2.2 XPointers Shall Be Straightforwardly Usable Over the Internet</a></h3>
<P>This implies the following:<UL>
<LI>Interoperability of XPointers and of client and server interpretation
of them is important.</LI>
<LI>Internationalization of XPointers is important. For example, we need
to ensure that string handling is internationalized.</LI>
</UL>
<H3><A NAME='2.3'>2.3 XPointers Shall Be Straightforwardly Usable in URIs</a></h3>
<P>Although XPointers can be used independently of XLinks, their primary use
is expected to be with URIs provided as part of XLinks. Therefore, we should
avoid creating confusion over separator characters and should avoid syntax
that would require character-escaping inside a URI.</P>
<H3><A NAME='2.4'>2.4 The XPointer Design Shall be Prepared Quickly</a></h3>
<P>As a critical component for the success of the XML family of specifications,
the XPointer language must be developed as quickly as possible.</P>
<H3><A NAME='2.5'>2.5 The XPointer Design Shall Be Formal and Concise</a></h3>
<P>XPointers should have a self-contained formal structure model
that minimally expresses the addressibility of
the various structures in an XML document (such as document, elements, attributes,
and so on). This formal model must be supplemented with crisp prose.</P>
<H3><A NAME='2.6'>2.6 The XPointer Syntax Shall Be Reasonably Compact and Human Readable</a></h3>
<P>There exist hypermedia addressing schemes that are very powerful but very
verbose. We believe that XPointer, to be usable by its Web audience, must
be expressible in a reasonably compact space; in particular, it needs to be
able to fit into an XML attribute value. It should also be readily understandable
in a single reading.</P>
<H3><A NAME='2.7'>2.7 XPointers Shall Be Optimized for Usability</a></h3>
<P>The XPointer language should reflect the ways people think naturally about
document structures and be mnemonic and intuitive to use. This may result
in multiple equivalent ways to point to the same data. For example, the <CODE>
child</CODE> and <CODE>string</CODE> keywords are probably sufficient to address
into any location, from a reductionist perspective, but providing only these
keywords would lead to awkward and unnatural XPointers in many cases.</P>
<H3><A NAME='2.8'>2.8 XPointers Must Be Feasible to Implement</a></h3>
<P>It is a nongoal for the XPointer language to be <EM>easy</EM> to implement
because we recognize that certain functionality is inherently difficult. Our
goal is to make implementation at least tractable; that is, we must consider
implementability in our deliberations.</P>
<P>For example, we are considering changing the "spanning" functionality so
that lookahead isn't required.</P>
<H2><A NAME='3'>3. References</a></h2>
<DL>
<dt><a name='ijdla'>IJDLa</a></dt><dd>Abiteboul, S., S. Cluet, V.
Christophides, T. Milo, G. Moerkotte, and J. Simeon. 1997. "Querying documents
in object databases." In International Journal on Digital Libraries
1(1). Springer-Verlag.</DD>
<dt><a name='ijdlb'>IJDLb</a></dt><dd>Abiteboul, S., D. Quass, J.
McHugh, J. Widom, J. L. Wiener. 1997. "The Lorel query language for semi-structured
data." In International Journal on Digital Libraries 1(1).
Springer-Verlag.</DD>
</DL>
<HR>