CR-xml-fragment-20010212 99.6 KB

Raw Blame History Permalink

<!DOCTYPE html
PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">

<html lang="EN">
  <head>
    <meta name="generator" content="HTML Tidy, see www.w3.org">
    <meta http-equiv="Content-Type" content=
    "text/html; charset=ISO-8859-1">
    <meta http-equiv="Content-Type" content=
    "text/html; charset=ISO-8859-1">

    <title>XML Fragment Interchange</title>
<style type="text/css">
code           { font-family: monospace; }

div.constraint,
div.issue,
div.note,
div.notice     { margin-left: 2em; }

dt.label       { display: run-in; }

li p           { margin-top: 0.3em;
                 margin-bottom: 0.3em; }

</style>
    <link rel="stylesheet" type="text/css" href=
    "http://www.w3.org/StyleSheets/TR/W3C-CR.css">
  </head>

  <body>
    <div class="head">
      <p><a href="http://www.w3.org/"><img src=
      "http://www.w3.org/Icons/w3c_home" alt="W3C" height="48"
      width="72"></a></p>

      <h1>XML Fragment Interchange</h1>

      <h2>W3C Candidate Recommendation 12 February 2001</h2>

      <dl>
        <dt>This version:</dt>

        <dd><a href=
        "http://www.w3.org/TR/2001/CR-xml-fragment-20010212">http://www.w3.org/TR/2001/CR-xml-fragment-20010212</a>
        (<a href=
        "http://www.w3.org/TR/2001/CR-xml-fragment-20010212.xml">XML</a>)</dd>

        <dt>Latest version:</dt>

        <dd><a href=
        "http://www.w3.org/TR/xml-fragment">http://www.w3.org/TR/xml-fragment</a></dd>

        <dt>Previous versions:</dt>

        <dd><a href=
        "http://www.w3.org/1999/06/WD-xml-fragment-19990630.html">http://www.w3.org/1999/06/WD-xml-fragment-19990630.html</a>
        <a href=
        "http://www.w3.org/1999/06/WD-xml-fragment-19990630.xml">http://www.w3.org/1999/06/WD-xml-fragment-19990630.xml</a>
        <a href=
        "http://www.w3.org/TR/1999/WD-xml-fragment-19990412.html">http://www.w3.org/TR/1999/WD-xml-fragment-19990412.html</a>
        <a href=
        "http://www.w3.org/TR/1999/WD-xml-fragment-19990412.xml">http://www.w3.org/TR/1999/WD-xml-fragment-19990412.xml</a>
        <a href=
        "http://www.w3.org/TR/1999/WD-xml-fragment-19990303.html">http://www.w3.org/TR/1999/WD-xml-fragment-19990303.html</a>
        <a href=
        "http://www.w3.org/TR/1999/WD-xml-fragment-19990303.xml">http://www.w3.org/TR/1999/WD-xml-fragment-19990303.xml</a></dd>

        <dt>Editors:</dt>

        <dd>Paul Grosso, Arbortext <a href=
        "mailto:pgrosso@arbortext.com">&lt;pgrosso@arbortext.com&gt;</a></dd>

        <dd>Daniel Veillard, W3C <a href=
        "mailto:veillard@w3.org">&lt;veillard@w3.org&gt;</a></dd>
      </dl>

      <p class="copyright"><a href=
      "http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Copyright">Copyright</a>&#160;©&#160;2001&#160;<a
       href="http://www.w3.org/"><abbr title=
      "World Wide Web Consortium">W3C</abbr></a><sup>®</sup> (<a
      href="http://www.lcs.mit.edu/"><abbr title=
      "Massachusetts Institute of Technology">MIT</abbr></a>, <a
      href="http://www.inria.fr/"><abbr lang="fr" title=
      "Institut National de Recherche en Informatique et Automatique">
      INRIA</abbr></a>, <a href="http://www.keio.ac.jp/">Keio</a>),
      All Rights Reserved. W3C <a href=
      "http://www.w3.org/Consortium/Legal/ipr-notice-20000612#Legal_Disclaimer">
      liability</a>, <a href=
      "http://www.w3.org/Consortium/Legal/ipr-notice-20000612#W3C_Trademarks">
      trademark</a>, <a href=
      "http://www.w3.org/Consortium/Legal/copyright-documents-19990405">
      document use</a>, and <a href=
      "http://www.w3.org/Consortium/Legal/copyright-software-19980720">
      software licensing</a> rules apply.</p>
    </div>
    <hr>

    <div>
      <h2><a name="abstract">Abstract</a></h2>

      <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&#8212;regardless of whether the fragments are
      predetermined entities or not&#8212;without having to send
      all of the containing document up to the part in question.
      This document defines Version 1.0 of the [eventual] W3C
      Recommendation that addresses this issue.</p>
    </div>

    <div>
      <h2><a name="status">Status of this Document</a></h2>

      <p>This specification is being put forth as a Candidate
      Recommendation by the <a href=
      "http://www.w3.org/XML/Activity#core-wg">XML Core Working
      Group</a>. This document is a revision of the <a href=
      "http://www.w3.org/1999/06/WD-xml-fragment-19990630">Working
      Draft dated 1999 June 30</a> which had incorporated
      suggestions received during last call review, comments, and
      further deliberations of the W3C XML Fragment Working Group.
      For background on this work, please see the <a href=
      "http://www.w3.org/XML/Activity.html#fragment-wg">XML
      Activity Statement</a>. The Working Group believes this
      specification to be stable and invites implementation
      feedback during this period.</p>

      <p>The duration of Candidate Recommendation is expected to
      last approximately three months (ending the end of April
      2001). All persons are encouraged to review and implement
      this specification and return comments to the <a href=
      "http://lists.w3.org/Archives/Public/www-xml-fragment-comments/">
      publicly archived</a> mailing list <a href=
      "mailto:www-xml-fragment-comments@w3.org">www-xml-fragment-comments@w3.org</a>.</p>

      <p>Should this specification prove impossible to implement,
      the Working Group will return the document to Working Draft
      status and make necessary changes. Otherwise, the Working
      Group anticipates asking the W3C Director to advance this
      document to Proposed Recommendation.</p>

      <p>This is still a draft document and may be updated,
      replaced, or obsoleted by other documents at any time. It is
      inappropriate to cite a W3C Candidate Recommendation as other
      than "work in progress." A list of current W3C working drafts
      can be found at <a href=
      "http://www.w3.org/TR">http://www.w3.org/TR</a>.</p>
    </div>

    <div class="toc">
      <h2><a name="contents">Table of Contents</a></h2>

      <p class="toc">1 <a href="#d1e200">Overview</a><br>
      2 <a href="#d1e250">Scope</a><br>
      3 <a href="#d1e275">Terminology</a><br>
      4 <a href="#d1e443">Fragment context information set</a><br>
      5 <a href="#d1e590">Fragment context specification
      notation</a><br>
      &#160;&#160;&#160;&#160;5.1 <a href=
      "#fcs-notn-overview">Overview of the fcs</a><br>
      &#160;&#160;&#160;&#160;5.2 <a href="#d1e763">Formal notation
      description</a><br>
      &#160;&#160;&#160;&#160;5.3 <a href=
      "#fcs-semantics">Semantics of a fragment context
      specification</a><br>
      &#160;&#160;&#160;&#160;5.4 <a href="#fcs-example">An fcs
      example</a><br>
      &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.4.1 <a
      href="#d1e1314">The parent Docbook book document</a><br>
      &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.4.2 <a
      href="#d1e1332">The fragment body</a><br>
      &#160;&#160;&#160;&#160;&#160;&#160;&#160;&#160;5.4.3 <a
      href="#d1e1347">The fragment context specification
      document</a><br>
      6 <a href="#d1e1378">Conformance</a><br>
      </p>

      <h3>Appendices</h3>

      <p class="toc">A <a href="#d1e1395">References</a><br>
      &#160;&#160;&#160;&#160;A.1 <a href="#d1e1400">Normative
      References</a><br>
      &#160;&#160;&#160;&#160;A.2 <a href="#d1e1440">Other
      References</a><br>
      B <a href="#packaging">Packaging and interchanging
      fragments</a> (Non-Normative)<br>
      C <a href="#examples">Examples</a> (Non-Normative)<br>
      &#160;&#160;&#160;&#160;C.1 <a href="#d1e1577">One element of
      a transaction record as a fragment</a><br>
      &#160;&#160;&#160;&#160;C.2 <a href="#d1e1604">Use of
      external entities and MIME packaging</a><br>
      &#160;&#160;&#160;&#160;C.3 <a href="#d1e1661">Indexes into a
      large document</a><br>
      D <a href="#d1e1674">Design Principles</a>
      (Non-Normative)<br>
      E <a href="#d1e1736">Acknowledgments</a> (Non-Normative)<br>
      F <a href="#d1e1781">Changes from Previous Public Working
      Drafts</a> (Non-Normative)<br>
      &#160;&#160;&#160;&#160;F.1 <a href="#d1e1786">Changes
      between the March 3 and April 2 WD</a><br>
      &#160;&#160;&#160;&#160;F.2 <a href="#d1e1853">Changes
      between the April 2 and June 19 WD</a><br>
      &#160;&#160;&#160;&#160;F.3 <a href="#d1e1894">Changes
      between the June 19 WD and the CR</a><br>
      </p>
    </div>
    <hr>

    <div class="body">
      <div class="div1">
        <h2><a name="d1e200"></a>1 Overview</h2>

        <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>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.</p>

        <p>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
        <b>fragment context specification</b>. The object
        representing the fragment removed from its source document
        is called the <b>fragment body</b>. 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 <b>fragment entity</b>. (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
        &#8220;sender,&#8221; &#8220;recipient,&#8221;
        &#8220;transmit,&#8221; 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
        &#8220;sender&#8221; and &#8220;recipient&#8221; may be on
        the same machine, node, system, or network, and may even be
        the same tool in different guises.)</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>

        <p>To accomplish these ends, this Recommendation
        defines:</p>

        <ul>
          <li>
            <p>exact constraints on what portions of an XML
            document may constitute fragments to be supported by
            this Recommendation;</p>
          </li>

          <li>
            <p>the set of information (fragment context
            information) that allows for successful parsing as well
            as for viewing or editing of a fragment in a useful and
            important set of cases;</p>
          </li>

          <li>
            <p>the notation (i.e., language) in which this
            information will be described (the fragment context
            specification);</p>
          </li>

          <li>
            <p>some mechanisms for associating this information
            with a fragment.</p>
          </li>
        </ul>
      </div>

      <div class="div1">
        <h2><a name="d1e250"></a>2 Scope</h2>

        <p>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.</p>

        <p>The goal of this activity is to define a way to send
        fragments of an XML document&#8212;regardless of whether
        the fragments are predetermined entities or
        not&#8212;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&#8212;and
        issues involved with the possible &#8220;return&#8221; of
        such a fragment to the original sender&#8212;is beyond the
        scope of this activity. While implementations of this
        Recommendation may serve as part of a larger system that
        allows for &#8220;fragment reuse,&#8221; the many important
        issues about reuse of XML text and &#8220;concurrent
        multiple author environments&#8221; are beyond the scope of
        this Recommendation.</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 (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.</p>

        <p>This Recommendation considers fragments of XML as
        defined by <a href="#XML">[XML 1.0]</a> and <a href=
        "#Namespaces">[XML Namespaces]</a>. 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.</p>

        <p>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)&#8212;other than such SGML that is, in fact, also
        well-formed XML&#8212;are not within scope of this
        Recommendation.</p>
      </div>

      <div class="div1">
        <h2><a name="d1e275"></a>3 Terminology</h2>

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

        <dl>
          <dt class="label">(well-formed) XML document</dt>

          <dd>
            <p>defined in <a href="#XML">[XML 1.0]</a>, <a href=
            "http://www.w3.org/TR/REC-xml#sec-well-formed">Well-formed
            XML documents</a></p>
          </dd>

          <dt class="label">(well-formed) (external) (parsed)
          entity</dt>

          <dd>
            <p>defined in <a href="#XML">[XML 1.0]</a>, <a href=
            "http://www.w3.org/TR/REC-xml#NT-extParsedEnt">production
            [78] extParsedEnt</a></p>
          </dd>

          <dt class="label"><a name=
          "defn-well-balanced"></a>(well-)balanced</dt>

          <dd>
            <p>A region (consecutive sequence of characters) of an
            XML document is said to be (well-)balanced if it
            matches <a href=
            "http://www.w3.org/TR/REC-xml#NT-content">production
            [43] content</a> of <a href="#XML">[XML 1.0]</a>.
            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).</p>
          </dd>

          <dt class="label"><a name=
          "defn-fragment"></a>fragment</dt>

          <dd>
            <p>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.</p>
          </dd>

          <dt class="label">fragment interchange</dt>

          <dd>
            <p>The process of receiving and/or parsing of a
            fragment by a fragment-aware application.</p>
          </dd>

          <dt class="label"><a name=
          "defn-fragment-body"></a>fragment body</dt>

          <dd>
            <p>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 &#8220;fragment body
            <em>in situ</em>.&#8221;</p>
          </dd>

          <dt class="label">context information</dt>

          <dd>
            <p>The abstract set of information&#8212;divorced from
            any particular language/syntax/notation&#8212;that
            constitutes the &#8220;parser state&#8221; 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.</p>
          </dd>

          <dt class="label"><a name=
          "defn-fragment-context-information"></a>(fragment)
          context (information)</dt>

          <dd>
            <p>(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.</p>
          </dd>

          <dt class="label"><a name=
          "defn-fragment-context-specification"></a>fragment
          context specification</dt>

          <dd>
            <p>(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.</p>
          </dd>

          <dt class="label">package [verb]</dt>

          <dd>
            <p>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.</p>
          </dd>

          <dt class="label"><a name=
          "defn-fragment-entity"></a>fragment entity</dt>

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

          <dt class="label"><a name=
          "defn-fragment-package"></a>(fragment) package
          [noun]</dt>

          <dd>
            <p>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
            (which presumably gets retrieved later) in which case
            the fragment package is the fragment context
            specification, and the fragment entity gets retrieved
            later.</p>
          </dd>

          <dt class="label"><a name=
          "defn-fcs-document"></a>fragment context specification
          document</dt>

          <dd>
            <p>As defined in this Recommendation, a valid fragment
            context specification (fcs) is a well-formed XML
            document. Therefore, when considered as a document, an
            fcs is sometimes referred to as a fragment context
            specification document (or fcs document). A fragment
            context specification document may also be a fragment
            package (i.e., it may be the actual object transmitted
            to effect fragment interchange).</p>
          </dd>

          <dt class="label">send/receive (and
          sender/recipient)</dt>

          <dd>
            <p>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
            &#8220;sender&#8221; and &#8220;recipient&#8221; 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).</p>
          </dd>
        </dl>
      </div>

      <div class="div1">
        <h2><a name="d1e443"></a>4 Fragment context information
        set</h2>

        <p>In this section, numbers in brackets refer to
        productions in <a href="#XML">[XML 1.0]</a>. The following
        information shall constitute the complete fragment context
        information (fci) set:</p>

        <ol>
          <li>
            <p>A reference to the external subset (extSubset [30]),
            by specifying an ExternalID [75] for it.</p>
          </li>

          <li>
            <p>Internal subset information using some or all of the
            following:</p>

            <ol>
              <li>
                <p>A reference to an &#8220;externalized
                copy&#8221; 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.</p>
              </li>

              <li>
                <p>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.</p>
              </li>
            </ol>
          </li>

          <li>
            <p>Ancestor information for the fragment body.</p>
          </li>

          <li>
            <p>Sibling information for the fragment body.</p>
          </li>

          <li>
            <p>Sibling information for any of the ancestors.</p>
          </li>

          <li>
            <p>Element content (aka descendant) information for any
            of the ancestors or siblings.</p>
          </li>

          <li>
            <p>Attribute information (attribute name and value)
            for:</p>

            <ol>
              <li>
                <p>any of the ancestors;</p>
              </li>

              <li>
                <p>any of the siblings of the fragment body;</p>
              </li>

              <li>
                <p>any of the siblings of any of the ancestors;</p>
              </li>

              <li>
                <p>any of the descendants of any of the ancestors
                or siblings.</p>
              </li>
            </ol>
          </li>

          <li>
            <p>A reference to the original/parental document by
            specifying an ExternalID [75] for it.</p>
          </li>

          <li>
            <p>A reference to the fragment body within the
            original/parental document by specifying an ExternalID
            [75].</p>
          </li>
        </ol>

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

        <ul>
          <li>
            <p>External subset</p>
          </li>

          <li>
            <p>Internal subset</p>
          </li>

          <li>
            <p>(Preceding) Siblings of the fragment body</p>
          </li>
        </ul>

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

        <ul>
          <li>
            <p>Ancestors</p>
          </li>

          <li>
            <p>(Preceding) Siblings of ancestors</p>
          </li>

          <li>
            <p>Following siblings of the fragment body and its
            ancestors</p>
          </li>

          <li>
            <p>Ancestor and sibling descendants</p>
          </li>

          <li>
            <p>Attributes</p>
          </li>
        </ul>

        <p>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:</p>

        <ul>
          <li>
            <p>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.</p>
          </li>

          <li>
            <p>A reference to the parent document.</p>
          </li>

          <li>
            <p>A reference to the fragment body <em>in
            situ</em>.</p>
          </li>
        </ul>
      </div>

      <div class="div1">
        <h2><a name="d1e590"></a>5 Fragment context specification
        notation</h2>

        <div class="div2">
          <h3><a name="fcs-notn-overview"></a>5.1 Overview of the
          fcs</h3>

          <p>The previous section defined the logical set of
          information possible in a fragment context. This section
          describes the notation in which to express a specific
          fragment context specification. All information would be
          optional; how much gets included in any particular
          fragment context specification is up to the sender and
          recipient, and how this gets determined is outside of the
          scope of this Recommendation.</p>

          <div class="note">
            <p class="prefix"><b>Note:</b></p>

            <p>While what gets included in any particular fragment
            context specification is outside of the scope of this
            Recommendation, some knowledge of the target
            application can help determine an appropriate level for
            the fcs. For example, if the target application is a
            user agent that will use Cascading Style Sheets (CSS)
            to display the fragment, the following information is
            necessary and sufficient given the current level of CSS
            selector capability: previous siblings of the fragment
            body, all ancestors of the fragment body, previous
            siblings of each of those ancestors, and all attributes
            on all those siblings and ancestors.</p>
          </div>

          <div class="note">
            <p class="prefix"><b>Note:</b></p>

            <p>A given fragment context specification need not
            necessarily provide the ability to specify the complete
            set of fragment context information described in the
            previous section. In particular, because the XML 1.0
            syntax for declarations is difficult to embed within an
            XML instance, the specific fragment context
            specification notation defined by this Recommendation
            does not 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
            &#8220;externalized copy&#8221; of the internal subset.
            Inline internal subset information may be more feasible
            once an instance syntax for declarations is defined,
            and such may be considered in future versions of the
            Fragment Interchange specification.</p>
          </div>

          <p>The syntax used is XML itself. In particular, a
          fragment context specification (fcs) is written as a
          single root XML element allowing up to five attributes
          and containing a subtree of other elements (possibly with
          attributes). The root element (and the element serving as
          the placeholder for the fragment body) comes from <a
          title="Fragment Interchange namespace" href=
          "#frag-ns-uri">Fragment Interchange namespace</a>, a
          specific namespace defined by this Recommendation; the
          contained subtree of elements comes from the namespace(s)
          of the document from which this fragment comes. For the
          purposes of exposition in this section, we assume
          namespace declarations such as the following are in
          force:</p>

          <table class="eg" cellpadding="5" border="1" bgcolor=
          "#99ffff" width="100%" summary="Example">
            <tr>
              <td>
<pre>
  xmlns:f="http://www.w3.org/2001/02/xml-fragment"
  xmlns="http://www.oasis-open.org/docbook/DocbookSchema"
</pre>
              </td>
            </tr>
          </table>

          <p>That is, within this example, <code>f</code> is the
          local prefix referring to the <a title=
          "Fragment Interchange namespace" href=
          "#frag-ns-uri">Fragment Interchange namespace</a> defined
          by this Recommendation for fragment-interchange related
          components, and the default namespace is that in effect
          in the parent document at the beginning of the fragment
          body <em>in situ</em>.</p>

          <p>The element type for the single root element for the
          fcs shall be <code>f:fcs</code> (where <code>f</code> is
          whatever namespace prefix is mapped to the <a title=
          "Fragment Interchange namespace" href=
          "#frag-ns-uri">Fragment Interchange namespace</a>). It
          allows up to five attributes, each of whose value shall
          be a URI reference [<a href="#rfc2396">[RFC 2396]</a>].
          The attribute names and the meaning of their values are
          as follows:</p>

          <dl>
            <dt class="label">extref</dt>

            <dd>
              <p>a URI reference to the external subset</p>
            </dd>

            <dt class="label">intref</dt>

            <dd>
              <p>a URI reference to the internal subset</p>
            </dd>

            <dt class="label">parentref</dt>

            <dd>
              <p>a URI reference to the parent document</p>
            </dd>

            <dt class="label">sourcelocn</dt>

            <dd>
              <p>a URI reference to the fragment body <em>in
              situ</em> within the parent document</p>
            </dd>
          </dl>

          <p>The content of the <code>f:fcs</code> element shall be
          a subtree of elements (possibly with attribute value
          assignments) from the parent document's namespace. This
          subtree shall provide all the structural context for the
          fragment body including various information about
          ancestor and sibling elements and attributes by mimicking
          the (relevant) context within this parent document. No
          data characters (mixed content) are allowed within the
          <code>f:fcs</code> element. The special empty element
          <code>f:fragbody</code> shall be used to indicate the
          placement of the fragment body within the specified
          context. It has one significant attribute with meaning as
          follows:</p>

          <dl>
            <dt class="label">fragbodyref</dt>

            <dd>
              <p>a URI reference [<a href="#rfc2396">[RFC
              2396]</a>] to the fragment body</p>
            </dd>
          </dl>

          <p>For example, consider a fragment body that consists of
          <code>listitems</code> 2 and 3 of an
          <code>orderedlist</code> (indicated to be enumerated with
          arabic numbers by the <code>numeration</code> attribute
          on the <code>orderedlist</code> element) within the
          second <code>sect1</code> within the first
          <code>chapter</code> within the first <code>part</code>
          within the <code>body</code> of a <code>book</code>.
          Assume that the external subset (aka &#8220;DTD&#8221;)
          is in the file <code>Docbook.dtd</code> on the OASIS Open
          web server, the parent document is in
          <code>mybook.xml</code> on Acme's web server, and that
          there need be no internal subset given as part of the
          fcs. Then the fcs for this fragment body might look
          like:</p>

          <table class="eg" cellpadding="5" border="1" bgcolor=
          "#99ffff" width="100%" summary="Example">
            <tr>
              <td>
<pre>
  &lt;f:fcs xmlns:f="http://www.w3.org/2001/02/xml-fragment"
         extref="http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd"
         parentref="http://www.acme.com/~me/mydocs/mybook.xml"
         xmlns="http://www.oasis-open.org/docbook/DocbookSchema"&gt;
    &lt;book&gt;
      &lt;part&gt;
        &lt;chapter&gt;
          &lt;sect1/&gt;
          &lt;sect1&gt;
            &lt;orderedlist numeration="arabic"&gt;
              &lt;listitem/&gt;
              &lt;f:fragbody/&gt;
            &lt;/orderedlist&gt;
          &lt;/sect1&gt;
        &lt;/chapter&gt;
      &lt;/part&gt;
    &lt;/book&gt;
  &lt;/f:fcs&gt;
</pre>
              </td>
            </tr>
          </table>
        </div>

        <div class="div2">
          <h3><a name="d1e763"></a>5.2 Formal notation
          description</h3>

          <p>A formal notation for the <code>fcs</code> element
          used in the examples of the previous section follows.
          Therein, the following terms are defined in either the
          &#8220;Extensible Markup Language (XML) 1.0&#8221; (<a
          href="#XML">[XML 1.0]</a>) or &#8220;Namespaces in
          XML&#8221; (<a href="#Namespaces">[XML Namespaces]</a>)
          Recommendations: <a href=
          "http://www.w3.org/TR/REC-xml-names/#NT-NCName">NCName</a>,
          <a href=
          "http://www.w3.org/TR/REC-xml#NT-AttValue">AttValue</a>,
          <a href="http://www.w3.org/TR/REC-xml#NT-Eq">Eq</a>, <a
          href="http://www.w3.org/TR/REC-xml#NT-S">S</a>, <a href=
          "http://www.w3.org/TR/REC-xml#NT-Attribute">Attribute</a>,
          <a href="http://www.w3.org/TR/REC-xml#NT-STag">STag</a>,
          <a href="http://www.w3.org/TR/REC-xml#NT-ETag">ETag</a>,
          <a href=
          "http://www.w3.org/TR/REC-xml#NT-EmptyElemTag">EmptyElemTag</a>,
          <a href=
          "http://www.w3.org/TR/REC-xml#NT-CharData">CharData</a>,
          <a href=
          "http://www.w3.org/TR/REC-xml#NT-Reference">Reference</a>,
          <a href=
          "http://www.w3.org/TR/REC-xml#NT-CDSect">CDSect</a>, <a
          href="http://www.w3.org/TR/REC-xml#NT-PI">PI</a>, <a
          href=
          "http://www.w3.org/TR/REC-xml#NT-Comment">Comment</a>, <a
          href="http://www.w3.org/TR/REC-xml#NT-prolog">prolog</a>,
          and <a href=
          "http://www.w3.org/TR/REC-xml#NT-Misc">Misc</a>.</p>

          <h5>Fragment Context Specification Element</h5>

          <table class="scrap" summary="Scrap">
            <tbody>
              <tr valign="baseline">
                <td><a name=
                "NT-FCSelement"></a>[1]&#160;&#160;&#160;</td>

                <td><code>FCSelement</code></td>

                <td>&#160;&#160;&#160;::=&#160;&#160;&#160;</td>

                <td><code><a href="#NT-FCSstag">FCSstag</a> <a
                href="http://www.w3.org/TR/REC-xml#NT-S">S</a>? <a
                href="#NT-FCSelementContent">FCSelementContent</a>
                <a href="http://www.w3.org/TR/REC-xml#NT-S">S</a>?
                <a href="#NT-FCSetag">FCSetag</a></code></td>
              </tr>
            </tbody>

            <tbody>
              <tr valign="baseline">
                <td><a name=
                "NT-FCSstag"></a>[2]&#160;&#160;&#160;</td>

                <td><code>FCSstag</code></td>

                <td>&#160;&#160;&#160;::=&#160;&#160;&#160;</td>

                <td><code>'&lt;' <a href=
                "http://www.w3.org/TR/REC-xml-names/#NT-NCName">NCName</a>
                ':fcs' ((<a href=
                "http://www.w3.org/TR/REC-xml#NT-S">S</a> 'extref'
                <a href="http://www.w3.org/TR/REC-xml#NT-Eq">Eq</a>
                <a href=
                "http://www.w3.org/TR/REC-xml#NT-AttValue">AttValue</a>)
                | (<a href=
                "http://www.w3.org/TR/REC-xml#NT-S">S</a> 'intref'
                <a href="http://www.w3.org/TR/REC-xml#NT-Eq">Eq</a>
                <a href=
                "http://www.w3.org/TR/REC-xml#NT-AttValue">AttValue</a>)
                | (<a href=
                "http://www.w3.org/TR/REC-xml#NT-S">S</a>
                'parentref' <a href=
                "http://www.w3.org/TR/REC-xml#NT-Eq">Eq</a> <a
                href=
                "http://www.w3.org/TR/REC-xml#NT-AttValue">AttValue</a>)
                | (<a href=
                "http://www.w3.org/TR/REC-xml#NT-S">S</a>
                'sourcelocn' <a href=
                "http://www.w3.org/TR/REC-xml#NT-Eq">Eq</a> <a
                href=
                "http://www.w3.org/TR/REC-xml#NT-AttValue">AttValue</a>)
                | (<a href=
                "http://www.w3.org/TR/REC-xml#NT-S">S</a> <a href=
                "http://www.w3.org/TR/REC-xml#NT-Attribute">Attribute</a>))*
                <a href="http://www.w3.org/TR/REC-xml#NT-S">S</a>?
                '&gt;'</code></td>

                <td><a href="#frag-ns">[Constraint: FCS Constraint:
                Fragment Namespace]</a></td>
              </tr>
            </tbody>

            <tbody>
              <tr valign="baseline">
                <td><a name=
                "NT-FCSelementContent"></a>[3]&#160;&#160;&#160;</td>

                <td><code>FCSelementContent</code></td>

                <td>&#160;&#160;&#160;::=&#160;&#160;&#160;</td>

                <td><code><a href=
                "http://www.w3.org/TR/REC-xml#NT-EmptyElemTag">EmptyElemTag</a>
                | <a href=
                "http://www.w3.org/TR/REC-xml#NT-STag">STag</a> <a
                href="#NT-FCScontent">FCScontent</a> <a href=
                "http://www.w3.org/TR/REC-xml#NT-ETag">ETag</a> |
                <a href=
                "#NT-FCSfragbody">FCSfragbody</a></code></td>

                <td><a href="#one-fragbody">[Constraint: FCS
                Constraint: Exactly One Fragbody]</a></td>
              </tr>
            </tbody>

            <tbody>
              <tr valign="baseline">
                <td><a name=
                "NT-FCSfragbody"></a>[4]&#160;&#160;&#160;</td>

                <td><code>FCSfragbody</code></td>

                <td>&#160;&#160;&#160;::=&#160;&#160;&#160;</td>

                <td><code>'&lt;' <a href=
                "http://www.w3.org/TR/REC-xml-names/#NT-NCName">NCName</a>
                ':fragbody' ((<a href=
                "http://www.w3.org/TR/REC-xml#NT-S">S</a>
                'fragbodyref' <a href=
                "http://www.w3.org/TR/REC-xml#NT-Eq">Eq</a> <a
                href=
                "http://www.w3.org/TR/REC-xml#NT-AttValue">AttValue</a>)
                | (<a href=
                "http://www.w3.org/TR/REC-xml#NT-S">S</a> <a href=
                "http://www.w3.org/TR/REC-xml#NT-Attribute">Attribute</a>))*
                <a href="http://www.w3.org/TR/REC-xml#NT-S">S</a>?
                '/&gt;'</code></td>

                <td><a href="#same-ns-prefix">[Constraint: FCS
                Constraint: Same Namespace Prefix]</a></td>
              </tr>
            </tbody>

            <tbody>
              <tr valign="baseline">
                <td><a name=
                "NT-FCSetag"></a>[5]&#160;&#160;&#160;</td>

                <td><code>FCSetag</code></td>

                <td>&#160;&#160;&#160;::=&#160;&#160;&#160;</td>

                <td><code>'&lt;/' <a href=
                "http://www.w3.org/TR/REC-xml-names/#NT-NCName">NCName</a>
                ':fcs' <a href=
                "http://www.w3.org/TR/REC-xml#NT-S">S</a>?
                '&gt;'</code></td>
              </tr>
            </tbody>

            <tbody>
              <tr valign="baseline">
                <td><a name=
                "NT-FCScontent"></a>[6]&#160;&#160;&#160;</td>

                <td><code>FCScontent</code></td>

                <td>&#160;&#160;&#160;::=&#160;&#160;&#160;</td>

                <td><code>(<a href=
                "#NT-FCSelementContent">FCSelementContent</a> | <a
                href=
                "http://www.w3.org/TR/REC-xml#NT-CharData">CharData</a>
                | <a href=
                "http://www.w3.org/TR/REC-xml#NT-Reference">Reference</a>
                | <a href=
                "http://www.w3.org/TR/REC-xml#NT-CDSect">CDSect</a>
                | <a href=
                "http://www.w3.org/TR/REC-xml#NT-PI">PI</a> | <a
                href=
                "http://www.w3.org/TR/REC-xml#NT-Comment">Comment</a>)*</code></td>
              </tr>
            </tbody>
          </table>

          <div class="constraint">
            <p class="prefix"><a name="frag-ns"></a><b>Constraint:
            FCS Constraint: Fragment Namespace</b></p>

            <p>The namespace prefix represented by <a href=
            "http://www.w3.org/TR/REC-xml-names/#NT-NCName">NCName</a>
            in the production for <a href="#NT-FCSstag">FCSstag</a>
            (and, therefore necessarily, <a href=
            "#NT-FCSetag">FCSetag</a>) must have been declared on
            one of the ancestors of the FCS element and must be
            associated with the Fragment Interchange Namespace URI
            defined in this Recommendation.</p>
          </div>

          <div class="constraint">
            <p class="prefix"><a name=
            "one-fragbody"></a><b>Constraint: FCS Constraint:
            Exactly One Fragbody</b></p>

            <p>There must be exactly one <code>fragbody</code> (<a
            href="#NT-FCSfragbody">FCSfragbody</a>) element in the
            fcs.</p>
          </div>

          <div class="constraint">
            <p class="prefix"><a name=
            "same-ns-prefix"></a><b>Constraint: FCS Constraint:
            Same Namespace Prefix</b></p>

            <p>The namespace prefix (<a href=
            "http://www.w3.org/TR/REC-xml-names/#NT-NCName">NCName</a>)
            used in the production for <a href=
            "#NT-FCSfragbody">FCSfragbody</a> must be the same as
            that used in the production for <a href=
            "#NT-FCSstag">FCSstag</a>.</p>
          </div>

          <p>[<a name="frag-ns-uri" title=
          "Fragment Interchange namespace">Definition</a>: The
          <b>fragment Interchange namespace</b> shall be associated
          with the following URI:
          <code>http://www.w3.org/2001/02/xml-fragment</code>.]</p>

          <p>In the productions for <a href=
          "#NT-FCSstag">FCSstag</a> and <a href=
          "#NT-FCSfragbody">FCSfragbody</a>, there can be any
          number of other attribute assignments, all of which are
          ignored by the fragment context specification processor.
          Per XML 1.0 compliance, there can be at most one
          assignment to any given attribute including the
          specifically mentioned attributes. (Since there is no
          &#8220;and&#8221; connector in EBNF, this restriction is
          difficult to show directly in the EBNF, hence this
          restriction in prose; however, this prose restriction is
          normative.)</p>

          <p>In the production for <a href=
          "#NT-FCScontent">FCScontent</a>, the fragment processor
          can optionally expand any <a href=
          "http://www.w3.org/TR/REC-xml#NT-Reference">Reference</a>s
          that it can expand. Then all <a href=
          "http://www.w3.org/TR/REC-xml#NT-CDSect">CDSect</a>s, <a
          href="http://www.w3.org/TR/REC-xml#NT-PI">PI</a>s, <a
          href=
          "http://www.w3.org/TR/REC-xml#NT-Comment">Comment</a>s,
          remaining <a href=
          "http://www.w3.org/TR/REC-xml#NT-Reference">Reference</a>s,
          and <a href=
          "http://www.w3.org/TR/REC-xml#NT-CharData">CharData</a>
          (including whitespace, <a href=
          "http://www.w3.org/TR/REC-xml#NT-S">S</a>) are ignored by
          the FCS processor.</p>

          <div class="note">
            <p class="prefix"><b>Note:</b></p>

            <p>If a <a href=
            "http://www.w3.org/TR/REC-xml#NT-Reference">Reference</a>
            in <a href="#NT-FCScontent">FCScontent</a> is expanded
            and the expansion includes element structure, that
            element structure is considered part of the fcs as it
            would if it had been included originally in its
            expanded form in the fcs. However, since expansion of
            any <a href=
            "http://www.w3.org/TR/REC-xml#NT-Reference">Reference</a>
            in <a href="#NT-FCScontent">FCScontent</a> is optional
            on the part of the fragment context specification
            processor, any sender for which such expansion is
            important should do the expansion when creating the
            fragment package.</p>
          </div>

          <h5>Fragment Context Specification</h5>

          <table class="scrap" summary="Scrap">
            <tbody>
              <tr valign="baseline">
                <td><a name="NT-fcs"></a>[7]&#160;&#160;&#160;</td>

                <td><code>FCS</code></td>

                <td>&#160;&#160;&#160;::=&#160;&#160;&#160;</td>

                <td><code><a href=
                "http://www.w3.org/TR/REC-xml#NT-prolog">prolog</a>
                <a href="#NT-FCSelement">FCSelement</a> <a href=
                "http://www.w3.org/TR/REC-xml#NT-Misc">Misc</a>*</code></td>

                <td><a href="#wf-nsc">[Constraint: FCS Constraint:
                Well-formed, namespace complete]</a></td>
              </tr>
            </tbody>
          </table>

          <div class="constraint">
            <p class="prefix"><a name="wf-nsc"></a><b>Constraint:
            FCS Constraint: Well-formed, namespace complete</b></p>

            <p>A fragment context specification shall constitute a
            well-formed document conforming to the
            &#8220;Extensible Markup Language (XML) 1.0&#8221; (<a
            href="#XML">[XML 1.0]</a>) and &#8220;Namespaces in
            XML&#8221; (<a href="#Namespaces">[XML Namespaces]</a>)
            Recommendations. In particular, if there are entity
            references in the fcs, the fcs document must comply
            with the <a href=
            "http://www.w3.org/TR/REC-xml#wf-entdeclared">Entity
            declared well-formedness constraint</a> per the
            &#8220;Extensible Markup Language (XML) 1.0&#8221; (<a
            href="#XML">[XML 1.0]</a>) Recommendation. (Appropriate
            declarations would appear in the internal subset of the
            fcs document.) Furthermore, for any use of namespaces,
            the fcs document must comply with the <a href=
            "http://www.w3.org/TR/REC-xml-names/#nsc-NSDeclared">Namespace
            declared namespace constraint</a> per the
            &#8220;Namespaces in XML&#8221; (<a href=
            "#Namespaces">[XML Namespaces]</a>) Recommendation.</p>
          </div>

          <div class="note">
            <p class="prefix"><b>Note:</b></p>

            <p>Generally, a fragment context specification document
            would be the well-formed document consisting simply of
            the <code>f:fcs</code> element (and its contents) with
            no prolog. However, a prolog is always allowable and
            might be necessary when some declarations are required
            to satisfy the <a href=
            "http://www.w3.org/TR/REC-xml#wf-entdeclared">Entity
            declared well-formedness constraint</a>.</p>
          </div>

          <div class="note">
            <p class="prefix"><b>Note:</b></p>

            <p>Since all of the components in <a href=
            "http://www.w3.org/TR/REC-xml#NT-prolog">prolog</a> are
            optional, an <a href="#NT-FCSelement">FCSelement</a> by
            itself is an allowable fragment context specification,
            and this Recommendation does not preclude some
            packaging scheme from combining an <a href=
            "#NT-FCSelement">FCSelement</a> along with a fragment
            body as shown in some of the examples in <a href=
            "#packaging"><b>B Packaging and interchanging
            fragments</b></a> and <a href="#examples"><b>C
            Examples</b></a>.</p>
          </div>
        </div>

        <div class="div2">
          <h3><a name="fcs-semantics"></a>5.3 Semantics of a
          fragment context specification</h3>

          <p>The previous section formally defines a fragment
          context specification to be a well-formed XML document
          consisting of a single <code>f:fcs</code> element with
          optional attributes and some content. The
          <code>f:fcs</code> element's content consists of optional
          stuff from the parent document (from which the fragment
          body is taken) plus a single <code>f:fragbody</code>
          element with optional attributes. The <code>f:fcs</code>
          and <code>f:fragbody</code> elements come from a
          namespace defined by this Recommendation and have certain
          specific semantics relative to fragment interchange as
          defined by this section.</p>

          <p>While it is important to be able to package a fragment
          body with its fcs, it is expected that a general
          XML-friendly packaging mechanism will be developed by the
          W3C that would satisfy this requirement. Meanwhile, this
          Recommendation defines a simple association mechanism
          that doesn't rely on a packaging scheme. Applications and
          interchange partners may agree on any packaging mechanism
          to aid in fragment interchange&#8212;this is beyond the
          scope of this Recommendation.</p>

          <p>The fcs document is a well-formed XML document that
          (1) provides the fragment context and (2) provides a
          reference to the fragment body. Because it is
          well-formed, existing XML processors can be used to
          process fcs documents. To support this fragment
          interchange Recommendation, an application must also
          understand the semantics of the <code>f:fcs</code> and
          <code>f:fragbody</code> elements and their attributes and
          process accordingly.</p>

          <p>Specifically, the <code>fragbodyref</code> attribute
          on the <code>fragbody</code> element is a URI reference
          [<a href="#rfc2396">[RFC 2396]</a>] to the fragment body.
          A fragment-aware processor is expected to resolve this
          reference and process the referenced fragment body in the
          context specified by the fcs. None of the attributes on
          the <code>fcs</code> element have required semantics with
          respect to fragment processing; they are provided
          (optionally) for the application's use at its
          discretion.</p>

          <div class="note">
            <p class="prefix"><b>Note:</b></p>

            <p>For example, a browser might bring up an fcs
            document, &#8220;expand&#8221; the reference to the
            fragment body (i.e., put a copy of the fragment body in
            place of the <code>fragbody</code> element), and then
            ignore (e.g., not display) the part of the document
            that was originally the fcs, thereby displaying (in the
            proper context) only the part of the document that was
            originally the fragment body.</p>
          </div>

          <div class="note">
            <p class="prefix"><b>Note:</b></p>

            <p>The <code>fragbody</code> element and its
            <code>fragbodyref</code> attribute are in many ways
            logically equivalent to an external entity reference or
            an XLink reference with an &#8220;embed&#8221;
            semantic.</p>
          </div>
        </div>

        <div class="div2">
          <h3><a name="fcs-example"></a>5.4 An fcs example</h3>

          <p>The following example shows the complete set of
          information relative to interchanging the two
          <code>listitem</code>s for the Docbook book mentioned in
          <a href="#fcs-notn-overview"><b>5.1 Overview of the
          fcs</b></a>.</p>

          <p>The parent document, in
          <code>~me/mydocs/mybook.xml</code> on Acme's web server,
          is a Docbook book document whose contents is outlined in
          the first subsection below. The fragment body of interest
          consists of <code>listitems</code> 2 and 3 of the
          <code>orderedlist</code> (indicated to be enumerated with
          arabic numbers by the <code>numeration</code> attribute
          on the <code>orderedlist</code> element) within the
          second <code>sect1</code> within the first
          <code>chapter</code> within the first <code>part</code>
          within the <code>body</code> of this <code>book</code>.
          The external subset (aka &#8220;DTD&#8221;) is in the
          file <code>Docbook.dtd</code> on the OASIS Open web
          server.</p>

          <div class="div3">
            <h4><a name="d1e1314"></a>5.4.1 The parent Docbook book
            document</h4>

            <p>The following represents the parent document from
            which the fragment body in question comes.</p>

            <table class="eg" cellpadding="5" border="1" bgcolor=
            "#99ffff" width="100%" summary="Example">
              <tr>
                <td>
<pre>
&lt;?xml version="1.0"?&gt;
&lt;!DOCTYPE book SYSTEM "http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd"&gt;
&lt;book xmlns="http://www.oasis-open.org/docbook/DocbookSchema"&gt;
  &lt;part&gt;
    &lt;chapter&gt;&lt;title&gt;The title for chapter one&lt;/title&gt;
      &lt;sect1&gt;&lt;title&gt;The title for section one in chapter one&lt;/title&gt;
        &lt;p&gt;The first paragraph....&lt;/p&gt;
        &lt;p&gt;....&lt;/p&gt;
      &lt;/sect1&gt;
      &lt;sect1&gt;&lt;title&gt;The title for section two in chapter one&lt;/title&gt;
        &lt;p&gt;An introductory paragraph preceding an ordered list.&lt;/p&gt;
        &lt;orderedlist numeration="arabic"&gt;
          &lt;listitem&gt;&lt;para&gt;This is the first listitem in this ordered
          list.&lt;/para&gt;&lt;/listitem&gt;
          &lt;listitem&gt;&lt;para&gt;This is the second listitem within the
          second sect1 of the first chapter within the first part
          of a Docbook &lt;quote&gt;book&lt;/quote&gt; document.&lt;/para&gt;&lt;/listitem&gt;
          &lt;listitem&gt;&lt;para&gt;And this is the next listitem.&lt;/para&gt;&lt;/listitem&gt;
          &lt;listitem&gt;&lt;para&gt;This is the fourth and last listitem.&lt;/para&gt;&lt;/listitem&gt;
        &lt;/orderedlist&gt;

        &lt;p&gt;Another paragraph....&lt;/p&gt;
      &lt;/sect1&gt;
    &lt;/chapter&gt;
    &lt;chapter&gt;&lt;title&gt;More content&lt;/title&gt;
      &lt;p&gt;More chapters, sections, paragraphs, and such....&lt;/p&gt;
    &lt;/chapter&gt;
  &lt;/part&gt;
&lt;/book&gt;
</pre>
                </td>
              </tr>
            </table>

            <p>Note that the declaration of the default namespace
            on the <code>&lt;book&gt;</code> tag isn't required for
            fragment interchange, but is shown for the purposes of
            completeness of this example.</p>
          </div>

          <div class="div3">
            <h4><a name="d1e1332"></a>5.4.2 The fragment body</h4>

            <p>The following shows the fragment body in a separate
            file ready for interchange. For the purposes of this
            example, we are assuming that this is in the file
            <code>~me/mydocs/myfrag.xml</code> on Acme's web
            server.</p>

            <table class="eg" cellpadding="5" border="1" bgcolor=
            "#99ffff" width="100%" summary="Example">
              <tr>
                <td>
<pre>
          &lt;listitem&gt;&lt;para&gt;This is the second listitem within the
          second sect1 of the first chapter within the first part
          of a Docbook &lt;quote&gt;book&lt;/quote&gt; document.&lt;/para&gt;&lt;/listitem&gt;
          &lt;listitem&gt;&lt;para&gt;And this is the next listitem.&lt;/para&gt;&lt;/listitem&gt;
</pre>
                </td>
              </tr>
            </table>
          </div>

          <div class="div3">
            <h4><a name="d1e1347"></a>5.4.3 The fragment context
            specification document</h4>

            <p>The following shows what the fcs document might look
            like for the above parent document and fragment body.
            If this were in the file (e.g.,
            <code>myfrag.fcs</code>), when this file is sent to any
            recipient with a fragment-aware tool, that tool should
            be able to access and process the desired fragment
            body.</p>

            <table class="eg" cellpadding="5" border="1" bgcolor=
            "#99ffff" width="100%" summary="Example">
              <tr>
                <td>
<pre>
  &lt;f:fcs xmlns:f="http://www.w3.org/2001/02/xml-fragment"
         extref="http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd"
         parentref="http://www.acme.com/~me/mydocs/mybook.xml"
         xmlns="http://www.oasis-open.org/docbook/DocbookSchema"&gt;
    &lt;book&gt;
      &lt;part&gt;
        &lt;chapter&gt;
          &lt;sect1/&gt;
          &lt;sect1&gt;
            &lt;orderedlist numeration="arabic"&gt;
              &lt;listitem/&gt;
              &lt;f:fragbody fragbodyref="http://www.acme.com/~me/mydocs/myfrag.xml"/&gt;
            &lt;/orderedlist&gt;
          &lt;/sect1&gt;
        &lt;/chapter&gt;
      &lt;/part&gt;
    &lt;/book&gt;
  &lt;/f:fcs&gt;
</pre>
                </td>
              </tr>
            </table>

            <p>Note that the <code>fragbodyref</code> value, which
            is a URI reference [<a href="#rfc2396">[RFC 2396]</a>],
            could be a URL, a file name, a MIME content id, etc.,
            depending on the MIME type of the referenced resource.
            Also note that the <code>parentref</code> value above
            is only there for the information of the receiving
            application, but is not necessary for this example's
            operation. Likewise, the <code>extref</code> would only
            be necessary if the receiving application wanted to be
            able to do validation.</p>
          </div>
        </div>
      </div>

      <div class="div1">
        <h2><a name="d1e1378"></a>6 Conformance</h2>

        <p>A fragment conforms to this XML Fragment Interchange
        Recommendation if it adheres to all syntactic requirements
        defined in this Recommendation. A fragment is syntactically
        correct if all of the requirements specified in Section 5.2
        are met.</p>

        <p>Application software acting as recipient 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.
        Specifically, conforming application software must be able
        to parse all conforming valid fragment context
        specification information whether it chooses to support its
        semantics or not. Application software acting as sender
        conforms to the XML Fragment Interchange Recommendation if
        it creates conforming XML fragments (as defined above) and,
        if including fragment context information, includes
        conforming fragment context information according to the
        requirements in section 4.</p>

        <p>If fragment context information is included with a
        transmitted fragment, then it should conform according to
        the requirements in section 4.</p>
      </div>
    </div>

    <div class="back">
      <div class="div1">
        <h2><a name="d1e1395"></a>A References</h2>

        <div class="div2">
          <h3><a name="d1e1400"></a>A.1 Normative References</h3>

          <dl>
            <dt class="label"><a name="rfc2396"></a>RFC 2396</dt>

            <dd>IETF RFC 2396: <em>Uniform Resource Identifiers
            (URI): Generic Syntax</em>. See <a href=
            "ftp://ftp.ietf.org/rfc/rfc2396.txt">ftp://ftp.ietf.org/rfc/rfc2396.txt</a></dd>

            <dt class="label"><a name="XML"></a>XML 1.0</dt>

            <dd>World Wide Web Consortium. <em>Extensible Markup
            Language (XML) 1.0.</em> W3C Recommendation. See <a
            href=
            "http://www.w3.org/TR/REC-xml">http://www.w3.org/TR/REC-xml</a></dd>

            <dt class="label"><a name="Namespaces"></a>XML
            Namespaces</dt>

            <dd>World Wide Web Consortium. <em>Namespaces in
            XML</em> W3C Proposed Recommendation. See <a href=
            "http://www.w3.org/TR/PR-xml-names">http://www.w3.org/TR/PR-xml-names</a></dd>

            <dt class="label"><a name=
            "AssocStylesheets"></a>Associating stylesheets</dt>

            <dd>World Wide Web Consortium. <em>Associating
            stylesheets with XML documents</em> W3C Working Draft.
            See <a href=
            "http://www.w3.org/TR/WD-xml-stylesheet">http://www.w3.org/TR/WD-xml-stylesheet</a></dd>
          </dl>
        </div>

        <div class="div2">
          <h3><a name="d1e1440"></a>A.2 Other References</h3>

          <dl>
            <dt class="label"><a name="TR9601"></a>TR9601</dt>

            <dd>OASIS (formerly SGML Open) <em>Fragment Interchange
            &#8212; SGML Open Technical Resolution 9601:1996</em>.
            OASIS (SGML Open) Technical Resolution. See <a href=
            "http://www.oasis-open.org/html/tr9601.html">http://www.oasis-open.org/html/tr9601.html</a>
            for an online version</dd>

            <dt class="label"><a name="MIME"></a>MIME</dt>

            <dd>IETF RFC 2045: <em>Multipurpose Internet Mail
            Extensions (MIME) Part One: Format of Internet Message
            Bodies</em>. See <a href=
            "http://www.imc.org/rfc2045">http://www.imc.org/rfc2045</a></dd>

            <dt class="label"><a name="rfc2387"></a>RFC 2387</dt>

            <dd>IETF RFC 2387: <em>The MIME Multipart/Related
            Content-type</em>. See <a href=
            "http://www.imc.org/rfc2387">http://www.imc.org/rfc2387</a></dd>

            <dt class="label"><a name="rfc2392"></a>RFC 2392</dt>

            <dd>IETF RFC 2392: <em>Content-ID and Message-ID
            Uniform Resource Locators</em>. See <a href=
            "ftp://ftp.ietf.org/rfc/rfc2392.txt">ftp://ftp.ietf.org/rfc/rfc2392.txt</a></dd>

            <dt class="label"><a name="XML-FRAG-REQ"></a>XML
            Fragment Requirements Document</dt>

            <dd>World Wide Web Consortium. <em>XML Fragment
            Interchange Requirements</em> W3C Note. See <a href=
            "http://www.w3.org/TR/NOTE-XML-FRAG-REQ">http://www.w3.org/TR/NOTE-XML-FRAG-REQ</a></dd>

            <dt class="label"><a name="XPointer"></a>XPointer
            WD</dt>

            <dd>World Wide Web Consortium. <em>XML Pointer Language
            (XPointer)</em> W3C Working Draft. See <a href=
            "http://www.w3.org/TR/WD-xptr">http://www.w3.org/TR/WD-xptr</a></dd>
          </dl>
        </div>
      </div>

      <div class="div1">
        <h2><a name="packaging"></a>B Packaging and interchanging
        fragments (Non-Normative)</h2>

        <p>It is a design goal of this Recommendation to define a
        fragment context specification to be a well-formed XML
        document. However, a fragment body itself need not be a
        well-formed document, but only well-balanced. While it is
        important to be able to package a fragment body with its
        fcs, it is expected that a general XML-friendly packaging
        mechanism&#8212;beyond the scope of this
        Recommendation&#8212;will be developed by the W3C that
        would satisfy this requirement. Meanwhile, applications and
        interchange partners may agree on any packaging mechanism
        to aid in fragment interchange. This appendix gives some
        non-normative examples of such possible packaging
        mechanisms.</p>

        <p>The <code>fcs</code> element could be packaged along
        with the fragment body by combining them into a single
        well-formed XML document. For the purposes of fragment
        interchange packaging, one could define a simple
        &#8220;document type&#8221; consisting of a
        &#8220;head&#8221; part containing the fcs (and,
        potentially, other) metadata followed by a
        &#8220;body&#8221; part containing the fragment body
        itself.</p>

        <p>In the following template, <code>p</code> is defined as
        the local prefix referring to the namespace defined for the
        packaging structure, and <code>f</code>, as in previous
        sections, is the local prefix referring to the namespace
        defined by this Recommendation for fragment-interchange
        related components. (Note that this template example
        assumes that no explicit namespace prefixes are present in
        the fragment body. If the fragment body contains explicit
        namespace prefixes whose declarations are not also included
        in the fragment body, then additional namespace
        declarations would be necessary on the
        <code>&lt;p:package&gt;</code> or
        <code>&lt;f:fcs&gt;</code> element. If the parent document
        does not use namespaces at all, then no default namespace
        declaration is needed for the fcs or its package.)</p>

        <p>The format of a complete fragment package might be
        outlined as follows:</p>

        <table class="eg" cellpadding="5" border="1" bgcolor=
        "#99ffff" width="100%" summary="Example">
          <tr>
            <td>
<pre>
&lt;p:package xmlns:p="http://www.w3.org/2001/02/xml-package"
           xmlns:f="http://www.w3.org/2001/02/xml-fragment"
           xmlns="<em>{the default namespace in effect at the start
                 of the fragment body in the parent document}</em>"&gt;
  &lt;f:fcs <em>{the ref attributes on the fcs tag}</em>&gt;
    <em>{the content of the fcs with no namespace prefixes
      necessary except that on the &lt;f:fragbody/&gt; element}</em>
  &lt;/f:fcs&gt;

  &lt;p:body&gt;
  <em>{the fragment body with no namespace prefixes necessary}</em>
  &lt;/p:body&gt;

&lt;/p:package&gt;
</pre>
            </td>
          </tr>
        </table>

        <div class="note">
          <p class="prefix"><b>Note:</b></p>

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

      <div class="div1">
        <h2><a name="examples"></a>C Examples (Non-Normative)</h2>

        <p>The following examples are designed in general to
        address the potential reference scenarios described in <a
        href="#XML-FRAG-REQ">[XML Fragment Requirements
        Document]</a>.</p>

        <div class="div2">
          <h3><a name="d1e1577"></a>C.1 One element of a
          transaction record as a fragment</h3>

          <p>The user has an XML document that represents a
          customer's set of purchases at a bookstore, and the part
          of that document that represents the purchase of a
          particular book needs to be represented as a
          fragment.</p>

          <p>Here is the original XML document for the
          transaction:</p>

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

          <p>Here is a fragment representing the second book
          element from the above document (the
          <code>sourcelocn</code> attribute on the
          <code>f:fcs</code> element is optional and is shown
          merely as an example):</p>

          <table class="eg" cellpadding="5" border="1" bgcolor=
          "#99ffff" width="100%" summary="Example">
            <tr>
              <td>
<pre>
&lt;?xml version="1.0"?&gt;
&lt;p:package xmlns:p="http://www.w3.org/2001/02/xml-package"&gt;
  &lt;p:fcs xmlns:f="http://www.w3.org/2001/02/xml-fragment"
         sourcelocn="http://acme.com/trans1234#root().child(1,purchase).child(2,book)"&gt;
    &lt;transaction&gt;
      &lt;purchase&gt;
        &lt;book/&gt;
    &lt;p:fragbody/&gt;
      &lt;/purchase&gt;
    &lt;/transaction&gt;
  &lt;/p:fcs&gt;

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

        <div class="div2">
          <h3><a name="d1e1604"></a>C.2 Use of external entities
          and MIME packaging</h3>

          <p>A user has an XML document that includes several
          external entities, and she wants to be able to
          interchange a fragment that includes a reference to the
          entities using MIME [<a href="#MIME">[MIME]</a>]
          packaging. (For references, see also <a href=
          "#rfc2387">[RFC 2387]</a> and <a href="#rfc2392">[RFC
          2392]</a>.)</p>

          <p>Here is the original document:</p>

          <table class="eg" cellpadding="5" border="1" bgcolor=
          "#99ffff" width="100%" summary="Example">
            <tr>
              <td>
<pre>
&lt;?xml version="1.0"?&gt;
&lt;!DOCTYPE book SYSTEM "http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd" [
&lt;!ENTITY title "My Book"&gt;
&lt;!ENTITY author "me"&gt;
&lt;!ENTITY try SYSTEM "try.cgm" NDATA CGM-BINARY&gt;
]&gt;
&lt;book&gt;
  &lt;part&gt;
    &lt;title&gt;&amp;title;&lt;/title&gt;
    &lt;introduction&gt;This is my book ...&lt;/introduction&gt;
    &lt;author&gt;&amp;author;&lt;/author&gt;
    &lt;chapter type="intro"&gt;
        &lt;sect1&gt;The introduction ...&lt;/sect1&gt;
    &lt;/chapter&gt;
    &lt;chapter&gt;...&lt;/chapter&gt;
    &lt;chapter&gt;
      &lt;p&gt;This is a paragraph within the third chapter within
the first part of a Docbook &lt;quote&gt;book&lt;/quote&gt; document.&lt;/p&gt;
      &lt;p&gt;And this is a succeeding paragraph.&lt;/p&gt;
      &lt;p&gt;And an internal text entity reference &amp;author;.&lt;/p&gt;
      &lt;p&gt;And a reference to an unparsed entity (a CGM graphic):
         &lt;graphic entityref="try"&gt;&lt;/graphic&gt;&lt;/p&gt;
    &lt;/chapter&gt;
    &lt;chapter&gt;...&lt;/chapter&gt;
  &lt;/part&gt;
&lt;/book&gt;
</pre>
              </td>
            </tr>
          </table>

          <p>Note that the DocBook DTD includes the following
          (which is therefore not included in the internal subset
          of this document):</p>

          <table class="eg" cellpadding="5" border="1" bgcolor=
          "#99ffff" width="100%" summary="Example">
            <tr>
              <td>
<pre>
&lt;!NOTATION CGM-BINARY PUBLIC "ISO 8632/3//NOTATION Binary Encoding//EN"&gt;
</pre>
              </td>
            </tr>
          </table>

          <p>Here is a fragment that represents the contents of the
          third chapter:</p>

          <table class="eg" cellpadding="5" border="1" bgcolor=
          "#99ffff" width="100%" summary="Example">
            <tr>
              <td>
<pre>
&lt;?xml version="1.0"?&gt;
&lt;f:fcs xmlns:f="http://www.w3.org/2001/02/xml-fragment"
       xmlns="http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd"
       extref="http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd"
       intref="mybook.decls"&gt;
    &lt;book&gt;
      &lt;part&gt;
        &lt;chapter type="intro"/&gt;
        &lt;chapter/&gt;
        &lt;chapter&gt;
            &lt;f:fragbody fragbodyref="chapter3.xml"/&gt;
        &lt;/chapter&gt;
      &lt;/part&gt;
    &lt;/book&gt;
  &lt;/f:fcs&gt;
</pre>
              </td>
            </tr>
          </table>

          <p>Here is the corresponding fragment body:</p>

          <table class="eg" cellpadding="5" border="1" bgcolor=
          "#99ffff" width="100%" summary="Example">
            <tr>
              <td>
<pre>
      &lt;p&gt;This is a paragraph within the third chapter within
the first part of a Docbook &lt;quote&gt;book&lt;/quote&gt; document.&lt;/p&gt;
      &lt;p&gt;And this is a succeeding paragraph.&lt;/p&gt;
      &lt;p&gt;And an internal text entity reference &amp;author;.&lt;/p&gt;
      &lt;p&gt;And a reference to an unparsed entity (a CGM graphic):
         &lt;graphic entityref="try"&gt;&lt;/graphic&gt;&lt;/p&gt;
</pre>
              </td>
            </tr>
          </table>

          <p>Here is the associated internal subset:</p>

          <table class="eg" cellpadding="5" border="1" bgcolor=
          "#99ffff" width="100%" summary="Example">
            <tr>
              <td>
<pre>
&lt;!ENTITY title "My Book"&gt;
&lt;!ENTITY author "me"&gt;
&lt;!ENTITY try SYSTEM "try.cgm" NDATA CGM-BINARY&gt;
</pre>
              </td>
            </tr>
          </table>

          <p>Here is the external entity (represented in Base 64
          encoding, since this is really a binary entity):</p>

          <table class="eg" cellpadding="5" border="1" bgcolor=
          "#99ffff" width="100%" summary="Example">
            <tr>
              <td>
<pre>
ACEAABAiAAEQXwBEQyJTb3VyY2U6IEhTSSAvV01GLXRvLUNHTSBmaWx0ZXIg
LyBWZXJzaW9uIDEuMzUgIiAiRGF0ZTogMTk5OS0wMS0xNyIRZgAB//8AARBi
AAAQpgAAAAkAFxFGAAAA////EYQwIgAQEYogyAAAAAB//3//AAARvwC3C1RJ
TUVTX1JPTUFODFRJTUVTX0lUQUxJQwpUSU1FU19CT0xEEVRJTUVTX0JPTERf
SVRBTElDCUhFTFZFVElDQRFIRUxWRVRJQ0FfT0JMSVFVRQ5IRUxWRVRJQ0Ff
Qk9MRBZIRUxWRVRJQ0FfQk9MRF9PQkxJUVVFB0NPVVJJRVIOQ09VUklFUl9J
VEFMSUMMQ09VUklFUl9CT0xEE0NPVVJJRVJfQk9MRF9JVEFMSUMGU1lNQk9M
ABHOAAABQgABAUEABAMqLToR4gABAGEAACAmAAE9NJ9IIEIAASBiAAAgggAA
IKIAACDI95D0wAhqCzoAAACAQWj5cAa5/TEJikGGAogCUQGQUGIACEAo+dD/
+v7g+TpRYgACUkwAAQAEAAAAAAAAAABRgBxUggAAABkAGQAAFKCAAJAkAEg/
MoAAQlTb21lIFRleHQAoABA
</pre>
              </td>
            </tr>
          </table>

          <p>And here is an example of MIME packaging used to
          transmit the fragment context specification, the fragment
          body, the internal subset, and the external entity within
          a single stream such as a mail message:</p>

          <table class="eg" cellpadding="5" border="1" bgcolor=
          "#99ffff" width="100%" summary="Example">
            <tr>
              <td>
<pre>
Content-Type: multipart/related; boundary="/04w6evG8XlLl3ft";type="text/xml"

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

&lt;!ENTITY title "My Book"&gt;
&lt;!ENTITY author "me"&gt;
&lt;!ENTITY try SYSTEM "cid:part2" NDATA CGM-BINARY&gt;

--/04w6evG8XlLl3ft
Content-Type: image/cgm
Content-ID: &lt;part2&gt;
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
Content-ID: &lt;part3&gt;
Content-Disposition: attachment; filename="chapter3.xml"

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

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

&lt;?xml version="1.0"?&gt;
&lt;f:fcs xmlns:f="http://www.w3.org/2001/02/xml-fragment"
       xmlns="http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd"
       extref="http://www.oasis-open.org/docbook/docbook/3.0/docbook.dtd"
       intref="cid:part1"&gt;
    &lt;book&gt;
      &lt;part&gt;
        &lt;chapter type="intro"/&gt;
        &lt;chapter/&gt;
        &lt;chapter&gt;
            &lt;f:fragbody fragbodyref="cid:part3"/&gt;
        &lt;/chapter&gt;
      &lt;/part&gt;
    &lt;/book&gt;
&lt;/f:fcs&gt;

--/04w6evG8XlLl3ft--
</pre>
              </td>
            </tr>
          </table>
        </div>

        <div class="div2">
          <h3><a name="d1e1661"></a>C.3 Indexes into a large
          document</h3>

          <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
          &#8220;index&#8221; for each document portion (fragment)
          that they wish to so address. The &#8220;index&#8221;
          consists of a fragment context specification in
          combination with a packaging mechanism designed for quick
          access to the fragment body. This should be used to view
          and browse documents with a flat structure, like HTML, on
          devices where only a part of the document can be parsed
          or rendered.</p>

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

      <div class="div1">
        <h2><a name="d1e1674"></a>D Design Principles
        (Non-Normative)</h2>

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

        <ol>
          <li>
            <p>XML fragment specifications should be usable over
            the internet.</p>
          </li>

          <li>
            <p>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
            &#8220;content&#8221; production (production [43]).
            Chunks of XML that do not match XML's
            &#8220;content&#8221; production (i.e., that are not
            well-formed entities) are specifically out of
            scope.</p>
          </li>

          <li>
            <p>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 (&#8220;the easy stuff should be
            easy, and the harder stuff should be possible&#8221;);
            working with SGML features not included in XML
            (including those, such as tag omission, allowed in
            HTML) is not a goal.</p>
          </li>

          <li>
            <p>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.</p>
          </li>

          <li>
            <p>XML fragment specifications should support
            interaction with XML browsers, editors, repositories,
            and other XML applications.</p>
          </li>

          <li>
            <p>SGML features and characteristics not included in
            XML shall not be taken into consideration in the design
            of our fragment context specification solution.</p>
          </li>

          <li>
            <p>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.</p>
          </li>

          <li>
            <p>Since interoperability is a primary goal, there
            should be only one language for the fragment context
            specification rather than multiple
            &#8220;features.&#8221; 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]&#8212;or not
            include [on the sending end]&#8212;a specific piece of
            context information if doing so makes sense in the
            particular environment.)</p>
          </li>

          <li>
            <p>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.</p>
          </li>

          <li>
            <p>XML fragment specifications should be human-readable
            and reasonably clear.</p>
          </li>

          <li>
            <p>Terseness in XML fragment specification syntax is of
            minimal importance.</p>
          </li>

          <li>
            <p>Issues involved with the possible
            &#8220;return&#8221; of any fragment to its original
            context and the determination of the possible validity
            of the &#8220;returned&#8221; fragment in its original
            context are beyond the scope of this activity.</p>
          </li>
        </ol>
      </div>

      <div class="div1">
        <h2><a name="d1e1736"></a>E Acknowledgments
        (Non-Normative)</h2>

        <p>The following participated in the XML Fragment WG during
        the authoring of this Recommendation:</p>

        <blockquote>
          <p>Paula Angerstein, Vignette<br>
          Tim Boland, NIST<br>
          Charles Frankston, Microsoft<br>
          Paul Grosso, Arbortext<br>
          Michael Hyman, Microsoft<br>
          Joel Nava, Adobe<br>
          Conleth O'Connell, Vignette<br>
          Joakim Östman, Citec<br>
          Christina Portillo, Boeing<br>
          Shriram Revankar, Xerox<br>
          Daniel Veillard, W3C</p>
        </blockquote>
      </div>

      <div class="div1">
        <h2><a name="d1e1781"></a>F Changes from Previous Public
        Working Drafts (Non-Normative)</h2>

        <div class="div2">
          <h3><a name="d1e1786"></a>F.1 Changes between the March 3
          and April 2 WD</h3>

          <p>Major changes to the previous public working draft are
          outlined below. Various other changes have also been made
          throughout the document.</p>

          <ol>
            <li>
              <p>Added <a href="#defn-fcs-document"><b>[fragment
              context specification document]</b></a> as a defined
              term.</p>
            </li>

            <li>
              <p>Added a <code>fragbodyref</code> attribute to the
              <code>fragbody</code> element (<a href=
              "#NT-FCSfragbody"><b>[PROD: 4]</b></a>) and renamed
              the <code>fragbodyref</code> attribute of the fcs
              element to <code>sourcelocn</code>.</p>
            </li>

            <li>
              <p>Added a production (<a href="#NT-fcs"><b>[PROD:
              7]</b></a>) to allow an fcs to have a prolog; added a
              well-formed, namespace complete FCS Constraint.</p>
            </li>

            <li>
              <p>Wrote a new subsection of the fcs notation chapter
              (<a href="#fcs-semantics"><b>5.3 Semantics of a
              fragment context specification</b></a>) describing
              the Semantics of a fragment context
              specification.</p>
            </li>

            <li>
              <p>Wrote a new subsection of the fcs notation chapter
              (<a href="#fcs-example"><b>5.4 An fcs
              example</b></a>) giving a complete example of a
              fragment context specification use (without
              packaging).</p>
            </li>

            <li>
              <p>Moved the chapter on packaging to the
              non-normative back matter (<a href="#packaging"><b>B
              Packaging and interchanging fragments</b></a>).</p>
            </li>

            <li>
              <p>Did major editing of the appendix of examples (<a
              href="#examples"><b>C Examples</b></a>).</p>
            </li>
          </ol>
        </div>

        <div class="div2">
          <h3><a name="d1e1853"></a>F.2 Changes between the April 2
          and June 19 WD</h3>

          <p>Major changes to the previous public working draft are
          outlined below. Various other minor changes have also
          been made to the document.</p>

          <ol>
            <li>
              <p>The Status section was updated.</p>
            </li>

            <li>
              <p>References to XPointer usage were replaced with
              references to &#8220;URI reference [RFC
              2396].&#8221;</p>
            </li>

            <li>
              <p>Some items in the fragment context information set
              were moved from the &#8220;affect proper
              parsing&#8221; list to the &#8220;cannot affect
              proper parsing&#8221; list.</p>
            </li>

            <li>
              <p>An additional note was added at the top of the
              Overview of the fcs to indicate what kinds of fci is
              necessary and sufficient for CSS use.</p>
            </li>

            <li>
              <p>The conformance section was expanded.</p>
            </li>

            <li>
              <p>References to related IETF RFC's were added.</p>
            </li>

            <li>
              <p>Example C.2 was modified to use content ids.</p>
            </li>
          </ol>
        </div>

        <div class="div2">
          <h3><a name="d1e1894"></a>F.3 Changes between the June 19
          WD and the CR</h3>

          <p>Changes to the previous public working draft are
          outlined below.</p>

          <ol>
            <li>
              <p>The Status section was updated.</p>
            </li>

            <li>
              <p>The Decision notes and review requests were
              removed.</p>
            </li>

            <li>
              <p>IDs were added on various elements to allow for
              more granular referencing.</p>
            </li>
          </ol>
        </div>
      </div>
    </div>
  </body>
</html>