You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
253 lines
12 KiB
253 lines
12 KiB
<!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>
|