The XML standard supports logical documents composed of possibly several entities. It may be desirable to view or edit one or more of the entities or parts of entities while having no interest, need, or ability to view or edit the entire document. The problem, then, is how to provide to a recipient of such a fragment the appropriate information about the context that fragment had in the larger document that is not available to the recipient.

In the case of many XML documents, it is suboptimal to have to receive and parse the entire document when only a fragment of it is desired. If the user asked to look at chapter 20, one shouldn't need to parse 19 whole chapters before getting to the part of interest. The goal of this activity is to define a way to enable processing of small parts of an XML document without having to process everything up to the part in question. This can be done regardless of whether the parts are entities or not, and the parts can either be viewed immediately or accumulated for later use, assembly, or other processing.

Conceptually, the holder of the complete source document considers a fragment of that document and, using the notation to be defined by this activity, constructs a fragment context specification. The object representing the fragment removed from its source document is called the fragment body. The fragment context specification and the fragment body are transmitted to the recipient. The storage object in which the fragment body is transmitted is call the fragment entity. (In some packaging schemes, the fragment context specification may also be embedded in the fragment entity.) The recipient processes the fragment context specification to determine the proper parser state for the context at the beginning of the fragment and uses that information to enable the XML parser to parse the fragment body. (The terms “sender,” “recipient,” “transmit,” are used throughout this document to describe the process of fragment interchange. It should be noted, however, that there are many feasible and useful scenarios for fragment interchange, and in some cases, the “sender” and “recipient” may be on the same machine, node, system, or network, and may even be the same tool in different guises.)

The challenge is that an isolated element from an XML document may not contain quite enough information to be parsed correctly. The goal of this activity is to enable senders to provide the remaining information required so that systems can interchange any XML elements they choose, from books or chapters all the way down to paragraphs, tables, footnotes, book titles, and so on, without having to manage each as a separate entity or having to risk incorrect parsing due to loss of context.

To accomplish these ends, this Recommendation defines:

This Recommendation enables interchanging portions of XML documents while retaining the ability to parse them correctly (that is, as they would be parsed in their originating document context), and, as far as practical, to be formatted, edited, and otherwise processed in useful ways.

The goal of this activity is to define a way to send fragments of an XML document—regardless of whether the fragments are predetermined entities or not—without having to send all of the containing document up to the part in question. The delivered parts can either be viewed or edited immediately or accumulated for later use, assembly, or other processing; what the receiving application does with the information—and issues involved with the possible “return” of such a fragment to the original sender—is beyond the scope of this activity. While implementations of this Recommendation may serve as part of a larger system that allows for “fragment reuse,” the many important issues about reuse of XML text and “concurrent multiple author environments” are beyond the scope of this Recommendation.

The point of the fragment context information is to provide information that is not available in the fragment body itself but that would be available from the complete XML document. Specifically, any information not available from the XML document (which may include an external subset) as a whole (plus knowledge of the location of the fragment body within the document) is out of scope for inclusion in the fragment context information. Such information may well be useful and important metadata in a variety of applications, but there are (or need to be) other mechanisms for handling this information.

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

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

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

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

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

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

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:

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

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

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

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

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

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