Few specifications are implemented in their entirety, in exactly the same way, by every implementor. Many specifications contain optional features or areas of acknowledged variation and some implementors choose to ignore required features that aren't needed by the community they serve, chosing to trade conformance for other benefits.

In the case of XML, there are exists not only optionality in the XML Recommendation itself, but there are a whole family of additional specifications which an implementor may choose to support or ignore. In principle, there are an enormous number of possible variations. In practice, there are dependencies between the specifications that limit the number of possible variations and implementors aren't motivated to implement completely arbitrary selections.

The Infoset gave the community a vocabulary for discussing the items produced by a parser. This specification gives the community a vocabulary for describing common sets of higher level features by describing profiles, collecting specific sets of features drawn from the family of specifications, and providing names for them.

One goal of this work is to help establish a lower bound on the number and nature of features supported. The ability to communicate by sending XML documents back and forth is predicated on the notion that we have the same understanding of those documents. While we might wish for the richest possible understanding, that's not likely to be supported by the widest range of implementations. Establishing a few basic profiles, we hope, provides a foundation on which other specifications can build.

The profile definitions which follow all assume that the starting point is a well-formed and namespace well-formed XML document. This specification does not consider documents that are not namespace well-formed. Documents which are not well-formed are not XML.

Each profile is defined in terms of conformance requirements on processors with respect to various XML-family specifications, and in terms of requirements on the information they provide to applications. Information provision requirements are specified by reference to classes of information items and properties, as further defined in .

It is the information itself which is required, not the particular packaging of it implied by the items and properties used to define those information classes. Processors typically package information in terms of more-or-less standardized data models or application program interfaces (APIs). How the information required for conformance to a particular profile defined below is conveyed by a data model or API need not correspond point-for-point to the Infoset terminology. For example, a data model may expose element content as an array of strings. That does not prevent it from conforming to the requirements expressed below in terms of the 's Character Information Items, for example requirement (3) of .

The four profiles defined here identify four increasingly rich profiles, in terms of kinds of processing and amount of information provided to applications, starting from a profile very close to what many XML processors do already in their minimal configuration:

The precise nature of each of these profiles is described in the sections which follow.

For the profile definitions above and the invariants below, we categorize the information expressed in XML documents, which may be made available to applications, into a number of (overlapping) classes. What follows is a complete tabulation of all the information items and their properties from , annotated with one or more class labels.

The tabulation which follows defines the information classes by enumerating their membership in terms of information items and their properties—each class contains all and only those items and properties against which its name appears below.

Whenever a document is processed in conformance with one of the profiles defined above, the information made available to applications will be guaranteed to have certain properties. The relation between the profiles and information classes defined above is summarized in the illustration below (PNG,SVG), then the sub-sections which follow describe this in terms of invariants with respect to the information made available.

The profiles defined here can be used as a starting point for the definition of further profiles. For example, the media type registrations for stylesheet languages applicable to XML such as application/xslt+xml or text/css might define a profile specifying appropriate <?xml-stylesheet type="[their media type]" . . .?> processing in addition to the processing required by .

Conformance to this specification means conformance by XML processors to profiles, as specified in .

Which profile or profiles an XML processor conforms to may depend on how it is configured. The conformance conditions for any specific processor configuration with respect to each profile are specified in the corresponding sub-section of .

Accordingly, any specification which references this one normatively is recommended to do so in terms such as "Conforming implementations must process XML documents and make information available as required by the id XML processor profile."

Specifying desired information outcomes is not sufficient to completely determine XML processor behaviour. In particular, if validation is performed and errors detected, the result may be no outcome at all.

A range of schema languages and approaches to validation exist. Some may provide for additional information items and/or properties which are not addressed by this specification. Also, the validation-dependent [element content whitespace] property of Character Information Items may only be reliably provided in conjunction with some approaches to validation, specifically DTD validation.

Furthermore, not all of the profiles defined above can be combined with all forms of validation: in particular, DTD validation requires that all external markup declarations be read and processed, and so cannot be required in conjunction with or .

Accordingly, specifications referencing this one should also specify whether validation is forbidden, optional or required, with respect to which schema language(s) with what validation control settings, if any. If the is involved, careful consideration is required as to whether validation is to happen before XInclude processing, or after, or both.