XML processor profiles

1 Introduction

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, choosing to trade conformance for other benefits.

In the case of XML, there are not only optional features 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 [XML Information Set] gave the community a vocabulary for discussing the information items passed by an XML processor to an application. 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.

2 XML processor profiles

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 3 Classes of Information.

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 define element content as an array of strings and not as an array of characters. That does not prevent it from conforming to the requirements expressed below in terms of the [XML Information Set]'s Character Information Items, for example requirement (3) of 2.1 The basic XML processor profile.

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 Basic profile adds only support for xml:base processing to the minimum expected of all processors, in order to allow for correct resolution of relative URIs;

• The Id profile adds xml:id processing in order to identify IDs in the possible absence of complete attribute type declaration information;

• The External Declarations profile adds mandatory external markup declaration processing in order to guarantee all information-affecting declarations are processed;

• The Full profile adds xi:include processing, in order to transclude linked infosets as parsed XML or as text, recursively as required.

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

<p:pipeline xmlns:p="http://www.w3.org/ns/xproc">

  <p:xinclude fixup-xml-base="true" fixup-xml-lang="true"/>

</p:pipeline>

3 Classes of Information

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 [XML Information Set], annotated with one or more class labels.

Class Core

Items and properties which are fundamental for all XML applications and so must be provided by all profiles.

Class Extended

Items and properties which depend on declarations and so must be provided by 2.3 The external declarations XML processor profile and 2.4 The full XML processor profile only. These items and properties may be absent if the 2.1 The basic XML processor profile or 2.2 The id XML processor profile are used.

Class Signal

Items and properties which only are relevant when entity declarations are not available and so must be provided by 2.1 The basic XML processor profile and 2.2 The id XML processor profile only.

Class Decl

Items and properties which depend on declarations. For 2.1 The basic XML processor profile and 2.2 The id XML processor profile, they will not be provided if the relevant declaration is in an unprocessed external entity, or is after the first reference to an external entity which is not processed.

Class Validated

Items and properties which will be present for validating processors, but for which support by non-validating processors is implementation-defined. Non-validating processors must document whether they provide this information to applications or not.

Class ImplDef

Items and properties for which support is implementation-defined. Processors must document whether they provide this information to applications or not.

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.

Document Information Item

the item itself	Core
[children]	ImplDef
[document element]	Core
[notations]	Extended, Decl
[unparsed entities]	Extended, Decl
[base URI]	Core
[character encoding scheme]	Core
[standalone]	Core
[version]	Core
[all declarations processed]	Core

Element Information Item

the item itself	Core
[namespace name]	Core
[local name]	Core
[prefix]	Core
[children]	Core
[attributes]	Core
[namespace attributes]	Core
[in-scope namespaces]	Core
[base URI]	Core
[parent]	Core

Attribute Information Item

the item itself	Core
[namespace name]	Core
[local name]	Core
[prefix]	Core
[normalized value]	Extended, Decl
[specified]	Core
[attribute type]	Extended, Decl
[references] to Element Information Items, i.e. for attributes of types IDREF and IDREFS	Extended, Decl
[references] to Notation and Unparsed Entity Information Items, i.e. for attributes of types ENTITY, ENTITIES and NOTATION	ImplDef
[owner element]	Core

Processing Instruction Information Item

the item itself	Core
[target]	Core
[content]	Core
[base URI]	Core
[notation]	ImplDef
[parent]	Core

Unexpanded Entity Reference Information Item

Note:

This type of information item will not occur at all if standalone="yes"is specified and is correct.

the item itself	Signal
all properties	Signal

Character Information Item

the item itself	Core
[character code]	Core
[element content whitespace]	Validated
[parent]	Core

Comment Information Item

the item itself	Core
[content]	Core
[parent]	Core

Document Type Declaration Information Item

the item itself	ImplDef
all properties	ImplDef

Unparsed Entity Information Item

the item itself	Extended, Decl
all properties	Extended, Decl

Notation Information Item

the item itself	Extended, Decl
all properties	Extended, Decl

Namespace Information Item

the item itself	Core
[prefix]	Core
[namespace name]	Core

4 Relations and Invariants

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.

Note: in an effort to maintain consistent relationships in the diagram, the label for the inner-most circle, around “Full Profile”, has been omitted. It should be read as if it was labeled “Perform XInclude processing”.

The following table summarizes the properties associated with each profile.

5 Other profiles (non-normative)

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 2.2 The id XML processor profile.

6 Validation (Non-normative)

Specifying desired information outcomes is not sufficient to completely determine XML processor behavior. 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 processed, and so cannot be required in conjunction with 2.1 The basic XML processor profile or 2.2 The id XML processor profile.

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 2.4 The full XML processor profile is involved, careful consideration is required as to whether validation is to happen before XInclude processing, or after, or both.