NOTE-XML-FRAG-REQ-19981123 15.9 KB

Raw Blame History Permalink

<!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">&lt;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>&nbsp;</td><td>
&nbsp;</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>
&#169;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>