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.
238 lines
16 KiB
238 lines
16 KiB
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
|
|
<!--ArborText, Inc., 1988-1998, v.4002-->
|
|
<html>
|
|
<head>
|
|
<title>XML Fragment Interchange Requirements</title>
|
|
<STYLE type="text/css">
|
|
BODY { color: black; background-color: white }
|
|
A:link { color: blue }
|
|
A:visited { color: #551A8B; }
|
|
</STYLE>
|
|
</head>
|
|
<body><h3 align="right"><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/WWW/w3c_home"
|
|
alt="W3C" align="left" border="0"></a>NOTE-XML-FRAG-REQ-19981123</h3><br clear="all"><h1
|
|
align="center">XML Fragment Interchange Requirements<br>Version 1.0</h1>
|
|
<h3 align="center">W3C Note 23-Nov-1998</h3>
|
|
<!--last revised $Date: 1998/11/29 20:06:56 $ by $Author: renaudb $-->
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
<dd><a href="http://www.w3.org/TR/1998/NOTE-XML-FRAG-REQ-19981123">http://www.w3.org/TR/1998/NOTE-XML-FRAG-REQ-19981123
|
|
</a></dd>
|
|
<dt>Latest version:</dt>
|
|
<dd><a href="http://www.w3.org/TR/NOTE-XML-FRAG-REQ">http://www.w3.org/TR/NOTE-XML-FRAG-REQ
|
|
</a></dd>
|
|
<dt>Previous versions: (Member Only)</dt>
|
|
<dd><a href="http://www.w3.org/XML/Group/1998/09/xml-frag-req">http://www.w3.org/XML/Group/1998/09/xml-frag-req
|
|
</a></dd>
|
|
<dd><a href="http://www.w3.org/XML/Group/1998/09/xml-frag-req-19980828">
|
|
http://www.w3.org/XML/Group/1998/09/xml-frag-req-19980828</a></dd>
|
|
<dd><a href="http://www.w3.org/XML/Group/1998/10/xml-frag-req-19981030">
|
|
http://www.w3.org/XML/Group/1998/10/xml-frag-req-19981030</a></dd>
|
|
<dt>Editor:</dt>
|
|
<dd>Paul Grosso (Arbortext) <a href="mailto:paul@arbortext.com"><paul@arbortext.com>
|
|
</a></dd>
|
|
</dl><div><h4>Status of this document</h4><p>This is a W3C Note produced as
|
|
a deliverable of the <a href="http://www.w3.org/XML/Group/Fragments">XML Fragment
|
|
WG</a> (<a href="http://www.w3.org/Help/AccessForm">members only</a>) according
|
|
to its charter and the current XML Activity process. A list of current W3C
|
|
working drafts and notes can be found at <a href="http://www.w3.org/TR">http://www.w3.org/TR
|
|
</a>.</p><p>This document is a work in progress representing the current consensus
|
|
of the W3C XML Fragment Working Group. This version of the XML Fragment Interchange
|
|
Requirements document has been approved by the XML Fragment working group
|
|
and the XML Plenary to be posted for review by W3C members and other interested
|
|
parties. Publication as a Note does not imply endorsement by the W3C membership.
|
|
Comments should be sent to <a href="mailto:www-xml-fragment-comments@w3.org">
|
|
www-xml-fragment-comments@w3.org</a>, which is an automatically and publicly
|
|
archived email list.</p><p>This document is being processed according to the
|
|
following review schedule:</p><table border="1" frame="border">
|
|
<caption>Review Schedule</caption>
|
|
<tbody>
|
|
<tr><th>Process</th><th>Closing date</th><th>Status</th><th>Contact</th></tr>
|
|
<tr><td>XML Fragment WG signoff</td><td>1998/11/04</td><td>done</td><td><a
|
|
href="http://www.w3.org/XML/Group/Fragments">XML Fragment WG</a></td></tr>
|
|
<tr><td>XML Plenary signoff</td><td>1998/11/20</td><td>done</td><td><a href="mailto:paul@arbortext.com,veillard@w3.org">
|
|
paul@arbortext.com,veillard@w3.org</a></td></tr>
|
|
<tr><td>Publish as W3C Note</td><td>1998/11/23</td><td>accepting comments
|
|
</td><td><a href="mailto:www-xml-fragment-comments@w3.org">www-xml-fragment-comments@w3.org
|
|
</a></td></tr>
|
|
<tr><td>Checkpoint of comments</td><td>1999/01/08</td><td> </td><td>
|
|
</td></tr>
|
|
</tbody></table><p>Comments about this document should be submitted to the
|
|
"contact" listed above for each process.</p></div>
|
|
<p><small>
|
|
<A HREF="http://www.w3.org/Consortium/Legal/ipr-notice.html#Copyright">Copyright</A>
|
|
©1998 <A HREF="http://www.w3.org">W3C</A> (<A HREF="http://www.lcs.mit.edu">MIT</A>,
|
|
<A HREF="http://www.inria.fr/">INRIA</A>, <A HREF="http://www.keio.ac.jp/">Keio</A>)
|
|
, All Rights Reserved. W3C <A HREF="http://www.w3.org/Consortium/Legal/ipr-notice.html#Lega
|
|
lDisclaimer">liability,</A>
|
|
<A HREF="http://www.w3.org/Consortium/Legal/ipr-notice.html#W3CTrademarks">trademark</A>,
|
|
<A HREF="http://www.w3.org/Consortium/Legal/copyright-documents.html">document
|
|
use</A> and <A HREF="http://www.w3.org/Consortium/Legal/copyright-software.html">software
|
|
licensing</A> rules apply.</small></p>
|
|
<div><h4>Abstract</h4><p>
|
|
The XML standard supports logical documents composed of possibly several entities.
|
|
It may be desirable to view or edit one or more of the entities or parts of
|
|
entities while having no interest, need, or ability to view or edit the entire
|
|
document. The problem, then, is how to provide to a recipient of such a fragment
|
|
the appropriate information about the context that fragment had in the larger
|
|
document that is not available to the recipient. The XML Fragment WG is chartered
|
|
with defining a way to send fragments of an XML document--regardless of whether
|
|
the fragments are predetermined entities or not--without having to send all
|
|
of the containing document up to the part in question. This document specifies
|
|
the design principles and requirements for this activity.</p></div><div><h3>
|
|
1. Overview</h3><p>The XML standard supports logical documents composed of
|
|
possibly several entities. It may be desirable to view or edit one or more
|
|
of the entities or parts of entities while having no interest, need, or ability
|
|
to view or edit the entire document. The problem, then, is how to provide
|
|
to a recipient of such a fragment the appropriate information about the context
|
|
that fragment had in the larger document that is not available to the recipient.
|
|
</p><p>The XML Fragment WG is chartered to work on a mechanism to address
|
|
these issues. The <a href="http://www.sgmlopen.org">SGML Open</a> <a href="http://www.sgmlopen.org/html/a601.htm">
|
|
Technical Resolution 9601:1996 on Fragment Interchange</a> provides a basis
|
|
for this work. This document specifies the design principles and requirements
|
|
for this activity.</p><p>In the case of many XML documents, it is suboptimal
|
|
to have to receive and parse the entire document when only a fragment of it
|
|
is desired. If the user asked to look at chapter 20, one shouldn't need to
|
|
parse 19 whole chapters before getting to the part of interest. The goal of
|
|
this activity is to define a way senders can send small parts of an XML document
|
|
without having to send everything up to the part needed. This can be done
|
|
regardless of whether the parts are entities or not, and the parts can either
|
|
be viewed immediately or accumulated for later use, assembly, or other processing.
|
|
</p><p>The challenge is that an isolated element from an XML document may
|
|
not contain quite enough information to be parsed correctly. The goal of this
|
|
activity is to enable senders to provide the remaining information required
|
|
so that systems can interchange any XML elements they choose, from books or
|
|
chapters all the way down to paragraphs, tables, footnotes, book titles, and
|
|
so on, without having to manage each as a separate entity or having to risk
|
|
incorrect parsing due to loss of context.</p></div><div><h3>2. Design Principles
|
|
</h3><p>In the design of any language, trade-offs in the solution space are
|
|
necessary. To aid in making these trade-offs the follow design principles
|
|
will be used (the order of these principles is not necessarily significant):
|
|
</p><ol>
|
|
<li>XML fragment specifications should be usable over the internet.</li>
|
|
<li>XML fragment specifications should support the specification of context
|
|
for any well-formed chunk of XML; the definition of a fragment may be broadened
|
|
to allow any chunk of XML that matches XML's "content" production (production
|
|
[43]). Chunks of XML that do not match XML's "content" production (i.e., that
|
|
are not well-formed entities) are specifically out of scope.</li>
|
|
<li>XML fragment specifications should be optimized to work with simpler XML
|
|
fragments (such as those conforming to the simpler XML profile being developed
|
|
by the XML Syntax WG), though the language should also work with any XML ("the
|
|
easy stuff should be easy, and the harder stuff should be possible"); working
|
|
with SGML features not included in XML (including those, such as tag omission,
|
|
allowed in HTML) is not a goal.</li>
|
|
<li>XML fragment specifications should be capable of being specified both
|
|
in the same storage object as the fragment body itself as well as in a separate
|
|
object linked in some fashion to the fragment body.</li>
|
|
<li>XML fragment specifications should support interaction with XML browsers,
|
|
editors, repositories, and other XML applications.</li>
|
|
<li>SGML features and characteristics not included in XML shall not be taken
|
|
into consideration in the design of our fragment context specification solution.
|
|
</li>
|
|
<li>It is specifically not a goal that XML fragment specifications be designed
|
|
in consideration of non-XML HTML browsers, parsers, or other non-XML applications.
|
|
</li>
|
|
<li>Since interoperability is a primary goal, there should be only one language
|
|
for the fragment context specification rather than multiple "features." However,
|
|
since the goal is to provide enough information to parse the fragment, and
|
|
well-formed XML may not require any extra information to allow it to be parsed,
|
|
no specific set of context information should be required in all context specifications.
|
|
(No implementation should choke on any valid piece of context information,
|
|
but no implementation should be considered non-compliant for choosing to ignore
|
|
[on the receiving end]--or not include [on the sending end]--a specific piece
|
|
of context information if doing so makes sense in the particular environment.)
|
|
</li>
|
|
<li>XML fragment specifications should leverage other recommendations and
|
|
standards, including XML 1.0, XML Namespace, XPointer, XML Information Set,
|
|
the SGML Open TR9601:1996 on Fragment Interchange, and relevant IETF work.
|
|
</li>
|
|
<li>XML fragment specifications should be human-readable and reasonably clear.
|
|
</li>
|
|
<li>Terseness in XML fragment specification syntax is of minimal importance.
|
|
</li>
|
|
<li><p>Issues involved with the possible "return" of any fragment to its original
|
|
context and the determination of the possible validity of the "returned" fragment
|
|
in its original context are beyond the scope of this activity.</p></li>
|
|
</ol></div><div><h3>3. Requirements</h3><p>This activity will enable interchanging
|
|
portions of XML documents while retaining the ability to parse them correctly
|
|
(that is, as they would be parsed in their originating document context),
|
|
and, as far as practical, to be formatted, edited, and otherwise processed
|
|
in useful ways.</p><p>Conceptually, a sender examines a fragment to be sent
|
|
and, using the notation to be defined by this activity, constructs a fragment
|
|
context specification. The object representing the fragment removed from its
|
|
source document is called the <em>fragment body</em>. The sender sends the
|
|
fragment context specification and the fragment body to the recipient. The
|
|
storage object in which the fragment body is transmitted is call the <em>
|
|
fragment entity</em>. (In some packaging schemes, the fragment context specification
|
|
may also be embedded in the fragment entity.) The recipient processes the
|
|
fragment context specification to determine the proper parser state for the
|
|
context at the beginning of the fragment and uses that information to enable
|
|
the XML parser to parse the fragment body.</p><p>The point of the fragment
|
|
context information is to provide information that is not available in the
|
|
fragment body itself but that would be available from the complete XML document.
|
|
Specifically, any information not available from the XML document as a whole
|
|
(plus knowledge of the location of the fragment body within the document)
|
|
is out of scope for inclusion in the fragment context information. Such information
|
|
may well be useful and important metadata in a variety of applications, but
|
|
there are (or need to be) other mechnisms for handling this information.</p><p>
|
|
Specifically a successful XML Fragment WG Recommendation will enable the following
|
|
scenarios:</p><ol>
|
|
<li>A sender can send a fragment that consists of any element or any sequence
|
|
of XML data that matches <a href="http://www.w3.org/TR/REC-xml#NT-content">
|
|
production 43 for "content" in the XML 1.0 Recommendation</a>. Most commonly
|
|
this means an element or a sequence of contiguous sibling elements, but character
|
|
data, processing instructions, comments, whitespace, and certain other XML
|
|
constructs may also be permitted.</li>
|
|
<li>The fragment can be parsed correctly at the recipient end to produce precisely
|
|
the same information set (XML structure and content information as defined
|
|
by the <a href="http://www.w3.org/XML/Group/Infoset.html">XML Information
|
|
Set WG</a>) that the sender got when it parsed the fragment in its complete
|
|
document context.</li>
|
|
<li>Where feasible, the fragment will be able to include information to aid
|
|
a recipient in determining how to present the fragment (e.g., to allow the
|
|
recipient to number headings as if the fragment were section 3 of appendix
|
|
B). This same information should allow the recipient to compute many link
|
|
anchors based on a hierarchical location in the original document.</li>
|
|
<li>Where feasible, the fragment will be able to include enough context information
|
|
to allow a recipient, such as a validating editor, to determine what modifications
|
|
would be valid or invalid given the larger document context. Note that the
|
|
maintenance of certain global validity constraints--such as document-wide
|
|
uniqueness of IDs--may be deemed unfeasible.</li>
|
|
<li>To allow for optimized interchange between systems that have special knowledge
|
|
of each other's capabilities and requirements, no specific piece of fragment
|
|
context information will be required (in particular, the "null" fragment context
|
|
specification would be a valid fragment context specification).</li>
|
|
</ol><p>To accomplish these ends, this activity will define:</p><ul>
|
|
<li>exact constraints on what portions of an XML document may constitute fragments
|
|
to be supported by this resolution;</li>
|
|
<li>the set of information needed to allow for successful parsing as well
|
|
as for viewing or editing of a fragment in a useful and important set of cases;
|
|
</li>
|
|
<li>the notation (i.e., language) in which this information (the fragment
|
|
context specification) will be described;</li>
|
|
<li>some mechanisms for associating this information with a fragment, with
|
|
at least one allowing for the fragment context specification to be included
|
|
in the same storage object as the fragment body and at least one allowing
|
|
for the fragment context specification to be in a storage object separate
|
|
from the fragment body.</li>
|
|
</ul></div><div><h3>A. Potential reference scenarios (Non-normative)</h3><div><h4>
|
|
A.1 One element of a transaction record as a fragment</h4><p>The user has
|
|
an XML document that represents a customer's set of purchases as a bookstore,
|
|
and the part of that document that represents the purchase of a particular
|
|
book needs to be represented as a fragment.</p></div><div><h4>A.2 A user selection
|
|
(aka highlighted region) as a fragment</h4><p>The user makes a well-balanced
|
|
selection in the original document and wants to make the contents of that
|
|
selection a fragment.</p></div><div><h4>A.3 Entities as fragments</h4><p>
|
|
A user has an XML document composed of several entities, and she wants to
|
|
be able to edit each entity standalone as well as having them referencable
|
|
from the parent document (i.e., each entity has to be both a valid XML entity
|
|
and a legal fragment at the same time).</p></div><div><h4>A.4 Indexes into
|
|
a large document</h4><p>The user has very large XML documents, possibly a
|
|
gigabyte or more in size, and wishes to be able to view portions of the document
|
|
without parsing the whole document. In order to do this the user creates an
|
|
"index" for each document portion (fragment) that they wish to so address.
|
|
The "index" consists of a fragment context specification in combination with
|
|
a packaging mechanism designed for quick access to the fragment body.</p></div></div><hr><p><a
|
|
href="http://validator.w3.org/"><img src="http://validator.w3.org/images/vh40.gif"
|
|
alt="Valid HTML 4.0!" height="31" width="88" border="0"></a></p></body>
|
|
</html>
|