XML Fragment Interchange

Table of Contents

• 1. Overview
• 2. Scope
• 3. Terminology
• 4. Fragment context information set
• 5. Fragment context specification notation
  • 5.1. Overview
  • 5.2. Formal notation description
• 6. Packaging and interchanging fragments
• 7. Conformance

• A. References
  • A.1. Normative References
  • A.2. Other References
• B. Examples
• C. Design Principles
• D. Acknowledgments
• E. Changes from Previous Public Working Draft

1. Overview

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.

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 to enable processing of small parts of an XML document without having to process everything up to the part in question. 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.

Conceptually, the holder of the complete source document considers a fragment of that document 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 fragment body. The fragment context specification and the fragment body are transmitted to the recipient. The storage object in which the fragment body is transmitted is call the fragment entity. (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. (The terms "sender," "recipient," "transmit," are used throughout this document to describe the process of fragment interchange. It should be noted, however, that there are many feasible and useful scenarios for fragment interchange, and in some cases, the "sender" and "recipient" may be on the same machine, node, system, or network, and may even be the same tool in different guises.)

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.

To accomplish these ends, this Recommendation defines:

• exact constraints on what portions of an XML document may constitute fragments to be supported by this Recommendation;
• 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;
• the notation (i.e., language) in which this information (the fragment context specification) will be described;
• 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.

2. Scope

This Recommendation enables 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.

The goal of this activity is to define 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. The delivered parts can either be viewed or edited immediately or accumulated for later use, assembly, or other processing; what the receiving application does with the information--and issues involved with the possible "return" of such a fragment to the original sender--is beyond the scope of this activity. While implementations of this Recommendation may serve as part of a larger system that allows for "fragment reuse," the many important issues about reuse of XML text and "concurrent multiple author environments" are beyond the scope of this Recommendation.

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 (which may include an external subset) 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 mechanisms for handling this information.

This Recommendation considers fragments of XML as defined by XML 1.0 and XML Namespaces . It is explicitly noted that this version of this Recommendation does not take into account work such as that taking place in the XML Schema Working Group; insofar as such work by other currently active working groups places new requirements on a fragment interchange solution, those requirements would be input to a new version of the fragment interchange specification that may become a chartered activity at a later date.

It is also explicitly noted that this Recommendation does not consider interchange of information that is not well-formed XML; in particular, issues specific to the interchange of fragments of SGML (including HTML)--other than such SGML that is, in fact, also well-formed XML--are not within scope of this Recommendation.

3. Terminology

This list is sorted "logically" as opposed to alphabetically. In an entry, phrases in parentheses are "optional" modifiers; whether they are used explicitly or not, we are still talking about the same thing for the purposed of this Recommendation.

(well-formed) XML document

defined in XML 1.0, Well-formed XML documents

(well-formed) (external) (parsed) entity

defined in XML 1.0, production [78] extParsedEnt

(well-)balanced

A region (consecutive sequence of characters) of an XML document is said to be (well-)balanced if it matches production [43] content of XML 1.0. Informally this means that, if the region includes any part of the markup of any construct, it contains all of the markup of that construct (e.g., in the case of elements, all of both the start and end tag).

fragment

A general term to refer to part of an XML document, plus possibly some extra information, that may be useful to use and interchange in the absence of the rest of the XML document. See the rest of the fragment-related terms when a more precise definition is required.

fragment interchange

The process of receiving and/or parsing of a fragment by a fragment-aware application.

fragment body

A well-balanced region of an XML document being considered as (logically and/or physically) separate from the rest of the document for the purposes of defining it as a fragment. Also, that part of a fragment entity that consists solely of the well-balanced region from the complete XML document. When it is important to indicate that a reference is specifically to the version of the fragment body still physically part of the originating (parent) document, this document will use the term "fragment body in situ."

context information

The abstract set of information--divorced from any particular language/syntax/notation--that constitutes the "parser state" at the point when a parser processing the complete XML document encounters (but has not yet processed) the first character of (what would be) the fragment body.

(fragment) context (information)

(sometimes abbreviated fci) The subset of the context information that we decide will be expressible in any fragment context specification language. Also the abstract set of information represented by a particular fragment context specification.

fragment context specification

(sometimes abbreviated fcs) A valid string in the language (notation) that this Recommendation defines that describes a set of fragment context information. Also the particular string in a fragment entity or fragment package that describes the fragment's context information.

package [verb]

To associate in some specified way a fragment body with a fragment context specification. This may include some way of combining both into a single XML-encoded object; combining both in some multipart MIME or archiving encoding; or linking the two via some sort of referencing, co-referencing, or third-party referencing scheme.

fragment entity

The storage object in which the fragment body is stored and/or transmitted during the process of fragment interchange.

(fragment) package [noun]

The object actually transmitted during the process of fragment interchange. Though one might expect this is the same thing as a fragment entity, the terms may or may not be synonyms in all cases; one could define a packaging mechanism whereby the fragment context specification is transmitted without the fragment body but somehow refers to the fragment body (which presumably gets retrieved later) in which case the fragment package is the fragment context specification, and the fragment entity either gets retrieved later or doesn't exist at all (e.g., the fragment context specification just has some sort of XPointer [XPointer WD] that defines the fragment body as part of the complete document).

send/receive (and sender/recipient)

In the context of this Recommendation, words such as send/receive (and sender/recipient) are used to described the general process of fragment interchange. There are many feasible and useful scenarios for fragment interchange, and in some cases, the "sender" and "recipient" may be on the same machine, node, system, or network, and may even be the same tool in different guises. The only constant assumption is that the sender has access to and knowledge of the entire (parental) document from which the fragment comes, and the recipient is in possession only of the fragment package (though nothing in this Recommendation precludes the possibility of the recipient using the information in the fragment package, if available, to attempt to fetch more information from the sender).

4. Fragment context information set

In this section, numbers in brackets refer to productions in XML 1.0. The following information shall constitute the complete fragment context information (fci) set:

1. A reference to the external subset (extSubset [30]), by specifying an ExternalID [75] for it.
2. Internal subset information using some or all of the following:
   1. A reference to an "externalized copy" of the internal subset (presumably generated by placing the internal declarations into a storage object such as extSubset [30]), presumably by specifying an ExternalID [75] for it.
   2. Some or all of markupdecl [29] and/or PEReference [69] allowed in an XML document's internal subset; note that PEReference implies expansion of what could be more external entities; also note that markupdecl includes comments, processing instructions, and declarations for elements, attribute lists, entities, and notations.
3. Ancestor information for the fragment body.
4. Sibling information for the fragment body.
5. Sibling information for any of the ancestors.
6. Element content (aka descendant) information for any of the ancestors or siblings.
7. Attribute information (attribute name and value) for:
   1. any of the ancestors;
   2. any of the siblings of the fragment body;
   3. any of the siblings of any of the ancestors;
   4. any of the descendants of any of the ancestors or siblings.
8. A reference to the original/parental document by specifying an ExternalID [75] for it.
9. A reference to the fragment body within the original/parental document by specifying an ExternalID [75] consisting of a URL plus an XPointer [XPointer WD].

From the above list, the following items affect proper (validating) parsing of the fragment:

• External subset
• Internal subset
• Ancestors
• (Preceding) Siblings of the fragment body
• (Preceding) Siblings of ancestors

The following items, while they cannot affect proper parsing, are usually considered part of the basic, structural XML parse tree:

• Following siblings of the fragment body and its ancestors
• Ancestor and sibling descendants
• Attributes

The following items, while not usually considered part of the basic, structural XML parse tree, are clearly definable pieces of information known or computable by any XML processor that is processing the parent document:

• XML declaration information of the parent document. Note that we have defined a fragment package to be an XML document. That is, the fragment package would contain its own XMLDecl-like information as necessary, so the fci itself need not include that information.
• A pointer (e.g., URL) to the parent document.
• A pointer (e.g., URL extended by one or two XPointer [ XPointer WD] specifications) to the fragment body in situ.

WG consensus decision: (1998/12/09): The WG decided that information such as copyright information and a pointer to the parent document's stylesheet was general metadata that shouldn't be included within the FCI set.

WG consensus decision: (1998/12/09): The WG decided not to allow for a "commenting" feature within the FCS as it was felt this was too subject to potential misuse.

WG consensus decision: (1999/01/06): The WG decided not to allow for an extension mechanism within the FCS since our packaging mechanism can be extended to allow the inclusion of other metadata, but the specification of that is outside the scope of this Recommendation.

WG consensus decision: (1999/01/06): Especially because the XML 1.0 syntax for declarations is difficult to embed within an XML instance, the WG decided not to allow for inline inclusion of internal subset information within the FCS; internal subset information can only be included in the FCS via a reference to an "externalized copy" of the internal subset. Inline internal subset information may be more feasible after the XML Schema WG defines instance syntax for declarations, but this would not make it into version 1.0 of this Fragment Interchange Recommendation.

5. Fragment context specification notation

  xmlns:f="http://www.w3.org/XML/Fragment/1.0"
  xmlns="http://www.oasis-open.org/docbook/DocbookSchema"

  <f:fcs extref="http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd"
         parentref="http://www.acme.com/~me/mydocs/mybook.xml">
    <book>
      <part>
        <chapter>
          <sect1/>
          <sect1>
            <orderedlist numeration="arabic">
              <listitem/>
              <f:fragbody/>
            </orderedlist>
          </sect1>
        </chapter>
      </part>
    </book>
  </f:fcs>

6. Packaging and interchanging fragments

The fcs is packaged along with the fragment body by combining them into a single well-formed XML document. For the purposed of fragment interchange packaging, this Recommendation defines a simple "document type" consisting of a "head" part containing the fcs (and, potentially, other) metadata followed by a "body" part containing the fragment body itself. (The XML Fragment WG notes that such a packaging mechanism could be extended to work with complete documents as well as fragment bodies and to include other metadata such as pointers to stylesheets, copyright information, and so on. This Recommendation defines the minimum necessary to support fragment interchange in the hopes that any other Recommendation that addresses packaging of XML documents would be able to be upward compatible with what has been done here.)

In the following example, p is the local prefix referring to the namespace defined (currently, by this Recommendation, but perhaps later by another "packaging" specification) for the packaging structure, and f, as in the previous section, is the local prefix referring to the namespace defined by this Recommendation for fragment-interchange related components.

The format of a complete fragment package is outlined as follows:

<p:package xmlns:p="http://www.w3.org/XML/Package/1.0"
           xmlns:f="http://www.w3.org/XML/Fragment/1.0"
           xmlns="{the namespace of the parent document}">
  <f:fcs {the ref attributes on the fcs tag}>
    {the content of the fcs with no namespace prefixes
      necessary except that on the <f:fragbody/> element}
  </f:fcs>

  <p:body>
  {the fragment body with no namespace prefixes necessary}
  </p:body>

</p:package>

For example, the complete fragment packages for the two listitems for the Docbook book mentioned in the previous section might look like:

<p:package xmlns:p="http://www.w3.org/XML/Package/1.0"
           xmlns:f="http://www.w3.org/XML/Fragment/1.0"
           xmlns="http://www.oasis-open.org/docbook/DocbookSchema">

  <f:fcs extref="http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd"
         parentref="http://www.acme.com/~me/mydocs/mybook.xml">
    <book>
      <part>
        <chapter>
          <sect1/>
          <sect1>
            <orderedlist numeration="arabic">
              <listitem/>
              <f:fragbody/>
            </orderedlist>
          </sect1>
        </chapter>
      </part>
    </book>
  </f:fcs>

  <p:body>
    <listitem><para>This is the second listitem within the
    second sect1 of the first chapter within the first part
    of a Docbook <quote>book</quote> document.</para></listitem>
    <listitem><para>And this is the next listitem.</para></listitem>
  </p:body>

</p:package>

Note

The above example includes indentation and blank lines to help display the overall structure of the package. However, all whitespace within the p:body element is significant and is therefore part of the fragment body. Therefore, the packaging process can introduce no whitespace (including record ends immediately following <p:body> and immediately preceding </p:body>) within the p:body element.

7. Conformance

A fragment conforms to this XML Fragment Interchange Recommendation if it adheres to all syntactic requirements defined in this Recommendation.

Application software conforms to the XML Fragment Interchange Recommendation if it interprets all conforming XML fragments (as defined above) according to all required semantics prescribed by this Recommendation, and, for any optional semantics it chooses to support, supports them in the way prescribed.

A. References

B. Examples

The following examples are designed in general to address the potential reference scenarios described in XML Fragment Requirements Document.

<?xml version="1.0"?>
<transaction TID="19990207-1234">
  <purchase>
    <book>
      <Author>Frank Herbert</Author>
      <Title>Dune</Title>
      <Edition>Hardcover Reissue edition (April 1984)</Edition>
      <ISBN>0399128964</ISBN>
      <Price currency="USD">18.87</Price>
      <Quantity>1</Quantity>
    </book>
    <book>
      <Author>J. R. R. Tolkien</Author>
      <Title>The Book of Lost Tales (The History of Middle-Earth)</Title>
      <Edition>Mass Market Paperback Reprint edition (June 1992)</Edition>
      <ISBN>0345375211</ISBN>
      <Price currency="USD">4.79</Price>
      <Quantity>1</Quantity>
    </book>
  </purchase>
  <refund RID="19990115-2">
    <reason TID="19981220-3214">Late delivery</reason>
    <value currency="USD">5.00</value>
  </refund>
  <payment>
    <client CID="123421"/>
    <value currency="USD">18.66</value>
    <creditcard type="MasterCard">
      <bank>BankBoston</bank>
      <owner>Joe J. Bill</owner>
      <serial>1234567890</serial>
      <expires>5/99</expires>
    </creditcard>
    <status>Waiting for approval</status>
  </payment>
</transaction>

<?xml version="1.0"?>
<p:package xmlns:p="http://www.w3.org/XML/Package/1.0"
           xmlns:f="http://www.w3.org/XML/Fragment/1.0"
           xmlns="">
  <f:fcs fragbodyref="http://sales.acme.com/trans/19990207-1234#root().child(1,purchase).child(2,book)">
    <transaction>
      <purchase>
        <book/>
        <f:fragbody/>
      </purchase>
    </transaction>
  </p:fcs>

  <p:body>
    <book>
      <Author>J. R. R. Tolkien</Author>
      <Title>The Book of Lost Tales (The History of Middle-Earth)</Title>
      <Edition>Mass Market Paperback Reprint edition (June 1992)</Edition>
      <ISBN>0345375211</ISBN>
      <Price currency="USD">4.79</Price>
      <Quantity>1</Quantity>
    </book>
  </p:body>
</p:package>

<?xml version="1.0"?>
<!DOCTYPE book SYSTEM "http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd" [
<!ENTITY title "My Book">
<!ENTITY author "me">
<!ENTITY try SYSTEM "try.cgm" NDATA CGM-BINARY>
]>
<book>
  <part>
    <title>&title;</title>
    <introduction>This is my book ...</introduction>
    <author>&author;</author>
    <chapter type="intro">
        <sect1>The introduction ...</sect1>
    </chapter>
    <chapter>...</chapter>
    <chapter>
      <p>This is a paragraph within the third chapter within
the first part of a Docbook <quote>book</quote> document.</p>
      <p>And this is a succeeding paragraph.</p>
      <p>And an internal text entity reference &author;.</p>
      <p>And a reference to an unparsed entity (a CGM graphic):
         <graphic entityref="try"></graphic></p>
    </chapter>
    <chapter>...</chapter>
  </part>
</book>

<!NOTATION CGM-BINARY PUBLIC "ISO 8632/3//NOTATION Binary Encoding//EN">

<?xml version="1.0"?>
<p:package xmlns:p="http://www.w3.org/XML/Package/1.0"
           xmlns:f="http://www.w3.org/XML/Fragment/1.0"
           xmlns="http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd">
  <f:fcs extref="http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd"
         intref="mybook.decls">
    <book>
      <part>
        <chapter type="intro"/>
        <chapter/>
        <chapter>
            <f:fragbody/>
        </chapter>
      </part>
    </book>
  </f:fcs>

  <p:body>
      <p>This is a paragraph within the third chapter within
the first part of a Docbook <quote>book</quote> document.</p>
      <p>And this is a succeeding paragraph.</p>
      <p>And an internal text entity reference &author;.</p>
      <p>And a reference to an unparsed entity (a CGM graphic):
         <graphic entityref="try"></graphic></p>
  </p:body>
</p:package>

<!ENTITY title "My Book">
<!ENTITY author "me">
<!ENTITY try SYSTEM "try.cgm" NDATA CGM-BINARY>

ACEAABAiAAEQXwBEQyJTb3VyY2U6IEhTSSAvV01GLXRvLUNHTSBmaWx0ZXIg
LyBWZXJzaW9uIDEuMzUgIiAiRGF0ZTogMTk5OS0wMS0xNyIRZgAB//8AARBi
AAAQpgAAAAkAFxFGAAAA////EYQwIgAQEYogyAAAAAB//3//AAARvwC3C1RJ
TUVTX1JPTUFODFRJTUVTX0lUQUxJQwpUSU1FU19CT0xEEVRJTUVTX0JPTERf
SVRBTElDCUhFTFZFVElDQRFIRUxWRVRJQ0FfT0JMSVFVRQ5IRUxWRVRJQ0Ff
Qk9MRBZIRUxWRVRJQ0FfQk9MRF9PQkxJUVVFB0NPVVJJRVIOQ09VUklFUl9J
VEFMSUMMQ09VUklFUl9CT0xEE0NPVVJJRVJfQk9MRF9JVEFMSUMGU1lNQk9M
ABHOAAABQgABAUEABAMqLToR4gABAGEAACAmAAE9NJ9IIEIAASBiAAAgggAA
IKIAACDI95D0wAhqCzoAAACAQWj5cAa5/TEJikGGAogCUQGQUGIACEAo+dD/
+v7g+TpRYgACUkwAAQAEAAAAAAAAAABRgBxUggAAABkAGQAAFKCAAJAkAEg/
MoAAQlTb21lIFRleHQAoABA

Content-Type: multipart/mixed; boundary="/04w6evG8XlLl3ft"

--/04w6evG8XlLl3ft
Content-Type: text/xml; charset=us-ascii
Content-Disposition: attachment; filename="mybook.decls"

<!ENTITY title "My Book">
<!ENTITY author "me">
<!ENTITY try SYSTEM "try.cgm" NDATA CGM-BINARY>

--/04w6evG8XlLl3ft
Content-Type: image/cgm
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="try.cgm"

ACEAABAiAAEQXwBEQyJTb3VyY2U6IEhTSSAvV01GLXRvLUNHTSBmaWx0ZXIg
LyBWZXJzaW9uIDEuMzUgIiAiRGF0ZTogMTk5OS0wMS0xNyIRZgAB//8AARBi
AAAQpgAAAAkAFxFGAAAA////EYQwIgAQEYogyAAAAAB//3//AAARvwC3C1RJ
TUVTX1JPTUFODFRJTUVTX0lUQUxJQwpUSU1FU19CT0xEEVRJTUVTX0JPTERf
SVRBTElDCUhFTFZFVElDQRFIRUxWRVRJQ0FfT0JMSVFVRQ5IRUxWRVRJQ0Ff
Qk9MRBZIRUxWRVRJQ0FfQk9MRF9PQkxJUVVFB0NPVVJJRVIOQ09VUklFUl9J
VEFMSUMMQ09VUklFUl9CT0xEE0NPVVJJRVJfQk9MRF9JVEFMSUMGU1lNQk9M
ABHOAAABQgABAUEABAMqLToR4gABAGEAACAmAAE9NJ9IIEIAASBiAAAgggAA
IKIAACDI95D0wAhqCzoAAACAQWj5cAa5/TEJikGGAogCUQGQUGIACEAo+dD/
+v7g+TpRYgACUkwAAQAEAAAAAAAAAABRgBxUggAAABkAGQAAFKCAAJAkAEg/
MoAAQlTb21lIFRleHQAoABA

--/04w6evG8XlLl3ft
Content-Type: text/xml; charset=us-ascii

<?xml version="1.0"?>
<p:package xmlns:p="http://www.w3.org/XML/Package/1.0"
           xmlns:f="http://www.w3.org/XML/Fragment/1.0"
           xmlns="http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd">
  <f:fcs extref="http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd"
         intref="mybook.decls">
    <book>
      <part>
        <chapter type="intro"/>
        <chapter/>
        <chapter>
            <f:fragbody/>
        </chapter>
      </part>
    </book>
  </f:fcs>

  <p:body>
      <p>This is a paragraph within the third chapter within
the first part of a Docbook <quote>book</quote> document.</p>
      <p>And this is a succeeding paragraph.</p>
      <p>And an internal text entity reference &author;.</p>
      <p>And a reference to an unparsed entity (a CGM graphic):
         <graphic entityref="try"></graphic></p>
  </p:body>
</p:package>

--/04w6evG8XlLl3ft--

<?xml version="1.0"?>
<p:package xmlns:p="http://www.w3.org/XML/Package/1.0"
           xmlns:f="http://www.w3.org/XML/Fragment/1.0"
           xmlns="">
  <f:fcs fragbodyref="http://www.w3.org/TR/REC-xml.html#sec-xml-and-sgml"
         extref="http://www.w3.org/TR/REC-html40-971218/loose.dtd">
    <html>
      <head>
        <link rel='STYLESHEET' type='text/css' href='/StyleSheets/TR/rec.css'/>
      </head>
      <body>
        <h1>Extensible Markup Language (XML) 1.0</h1>
        <h2 ID='sec-intro'>1. Introduction</h2>
        <h3 ID='sec-origin-goals'>1.1 Origin and Goals</h3>
        <h3 ID='sec-terminology'>1.2 Terminology</h3>
        <h2 ID='sec-documents'>2. Documents</h2>
        <h3 ID='sec-well-formed'>2.1 Well-Formed XML Documents</h3>
        <h3 ID='charsets'>2.2 Characters</h3>
        <h3 ID='sec-common-syn'>2.3 Common Syntactic Constructs</h3>
        <h3 ID='syntax'>2.4 Character Data and Markup</h3>
        <h3 ID='sec-comments'>2.5 Comments</h3>
        <h3 ID='sec-pi'>2.6 Processing Instructions</h3>
        <h3 ID='sec-cdata-sect'>2.7 CDATA Sections</h3>
        <h3 ID='sec-prolog-dtd'>2.8 Prolog and Document Type Declaration</h3>
        <h3 ID='sec-rmd'>2.9 Standalone Document Declaration</h3>
        <h3 ID='sec-white-space'>2.10 White Space Handling</h3>
        <h3 ID='sec-line-ends'>2.11 End-of-Line Handling</h3>
        <h3 ID='sec-lang-tag'>2.12 Language Identification</h3>
        <h2 ID='sec-logical-struct'>3. Logical Structures</h2>
        <h3 ID='sec-starttags'>3.1 Start-Tags, End-Tags, and Empty-Element Tags</h3>
        <h3 ID='elemdecls'>3.2 Element Type Declarations</h3>
        <h4 ID='sec-element-content'>3.2.1 Element Content</h4>
        <h4 ID='sec-mixed-content'>3.2.2 Mixed Content</h4>
        <h3 ID='attdecls'>3.3 Attribute-List Declarations</h3>
        <h4 ID='sec-attribute-types'>3.3.1 Attribute Types</h4>
        <h4 ID='sec-attr-defaults'>3.3.2 Attribute Defaults</h4>
        <h4 ID='AVNormalize'>3.3.3 Attribute-Value Normalization</h4>
        <h3 ID='sec-condition-sect'>3.4 Conditional Sections</h3>
        <h2 ID='sec-physical-struct'>4. Physical Structures</h2>
        <h3 ID='sec-references'>4.1 Character and Entity References</h3>
        <h3 ID='sec-entity-decl'>4.2 Entity Declarations</h3>
        <h4 ID='sec-internal-ent'>4.2.1 Internal Entities</h4>
        <h4 ID='sec-external-ent'>4.2.2 External Entities</h4>
        <h3 ID='TextEntities'>4.3 Parsed Entities</h3>
        <h4 ID='sec-TextDecl'>4.3.1 The Text Declaration</h4>
        <h4 ID='wf-entities'>4.3.2 Well-Formed Parsed Entities</h4>
        <h4 ID='charencoding'>4.3.3 Character Encoding in Entities</h4>
        <h3 ID='entproc'>4.4 XML Processor Treatment of Entities and References</h3>
        <h4 ID='not-recognized'>4.4.1 Not Recognized</h4>
        <h4 ID='included'>4.4.2 Included</h4>
        <h4 ID='include-if-valid'>4.4.3 Included If Validating</h4>
        <h4 ID='forbidden'>4.4.4 Forbidden</h4>
        <h4 ID='inliteral'>4.4.5 Included in Literal</h4>
        <h4 ID='notify'>4.4.6 Notify</h4>
        <h4 ID='bypass'>4.4.7 Bypassed</h4>
        <h4 ID='as-PE'>4.4.8 Included as PE</h4>
        <h3 ID='intern-replacement'>4.5 Construction of Internal Entity Replacement Text</h3>
        <h3 ID='sec-predefined-ent'>4.6 Predefined Entities</h3>
        <h3 ID='Notations'>4.7 Notation Declarations</h3>
        <h3 ID='sec-doc-entity'>4.8 Document Entity</h3>
        <h2 ID='sec-conformance'>5. Conformance</h2>
        <h3 ID='proc-types'>5.1 Validating and Non-Validating Processors</h3>
        <h3 ID='safe-behavior'>5.2 Using XML Processors</h3>
        <h2 ID='sec-notation'>6. Notation</h2>
        <h3>Appendices</h3>A. <A ID='sec-bibliography'>References</A>
        <h3 ID='sec-existing-stds'>A.1 Normative References</h3>
        <h3 ID='null'>A.2 Other References</h3>
        <h2 ID='CharClasses'>B. Character Classes</h2>
        <f:fragbody/>
        <h2 ID='sec-entexpand'>D. Expansion of Entity and Character References (Non-Normative)</h2>
        <h2 ID='determinism'>E. Deterministic Content Models (Non-Normative)</h2>
        <h2 ID='sec-guessing'>F. Autodetection of Character Encodings (Non-Normative)</h2>
        <h2 ID='sec-xml-wg'>G. W3C XML Working Group (Non-Normative)</h2>
      </body>
    </html>
  </f:fcs>

  <p:body>
<h2 ID='sec-xml-and-sgml'>C. XML and SGML (Non-Normative)</h2>
<p>XML is designed to be a subset of SGML, in that every
<a IDREF='#dt-valid'>valid</a> XML document should also be a
conformant SGML document.
For a detailed comparison of the additional restrictions that XML places on
documents beyond those of SGML, see <a IDREF='#Clark'>[Clark]</a>.
</p>
  </p:body>
</p:package>

C. Design Principles

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 were used (the order of these principles is not necessarily significant):

1. XML fragment specifications should be usable over the internet.
2. 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.
3. 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.
4. 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.
5. XML fragment specifications should support interaction with XML browsers, editors, repositories, and other XML applications.
6. SGML features and characteristics not included in XML shall not be taken into consideration in the design of our fragment context specification solution.
7. 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.
8. 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.)
9. 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.
10. XML fragment specifications should be human-readable and reasonably clear.
11. Terseness in XML fragment specification syntax is of minimal importance.
12. 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.

D. Acknowledgments

The following participated in the XML Fragment WG during the authoring of this Recommendation:

• Paul Angerstein, Vignette
• Tim Boland, NIST
• Charles Frankston, Microsoft
• Paul Grosso, Arbortext
• Michael Hyman, Microsoft
• Jole Nava, Adobe
• Conleth O'Connell, Vignette
• Joakim Östman, Citec
• Christina Portillo, Boeing
• Shriram Revankar, Xerox
• Daniel Veillard, W3C

E. Changes from Previous Public Working Draft

N/A.