XML processor profiles

1 Background

The XML specification [Extensible Markup Language (XML) 1.0 (Fifth Edition)] defines an XML processor as "a software module. . .used to read XML documents and provide access to their content and structure. . .on behalf of another module, called the application." XML applications are often defined by building on top of the [XML Information Set] vocabulary or XML data models such as [XML Path Language (XPath) Version 1.0] or [XQuery 1.0 and XPath 2.0 Data Model (XDM)], understood as the output of an XML processor. Such definitions have suffered to some extent from an uncertainty inherent in using that kind of foundation, in that the mapping XML processors perform from XML documents to data model is not rigid. Some of this stems from the XML specification itself, which is not always explicit about what information must be passed from processor to application, and which also leaves open the possiblity of reading and interpreting external entities, or not. Another kind of uncertainty stems from the growth of the XML family of specifications: if the input document includes uses of XInclude, for instance.

This specification addresses this issue by defining several XML processor profiles, each of which fully determines a data model for any given XML document. It is intended as a resource for other specifications, which can by a single normative reference establish precisely what input processing they require.

The profiles defined here are appropriate for processing both XML 1.0 [Extensible Markup Language (XML) 1.0 (Fifth Edition)] and XML 1.1 [Extensible Markup Language (XML) 1.1 (Second Edition)] documents. References to XML or XML Namespaces below should be understood as references to 1.0 or 1.1 as required by the relevant document or application.

2 XML processor profiles

All of the profiles describe the steps necessary to construct a data model from 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 comformance requirements with respect to various XML-family specifications, and in terms of requirements on the information it provides to applications. Information provision requirements are specified by reference to classes of information items and properties, as further defined in 3 Classes of Information.

<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 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 AClass A

Items and properties which must be provided by all profiles.

Class BClass B

Items and properties which must be provided by 2.3 The modest XML processor profile and 2.4 The recommended XML processor profile

Class B'Class B'

Items and properties which must be provided by 2.1 The minimum XML processor profile and 2.2 The basic XML processor profile

Class PClass P

Items and properties which depend on declarations. For 2.1 The minimum XML processor profile and 2.2 The basic 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 VClass V

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

Class XClass X

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

Document Information ItemDocument Information Item

the item itself	A
[children]	X
[document element]	A
[notations]	B, P
[unparsed entities]	B, P
[base URI]	A
[character encoding scheme]	A
[standalone]	A
[version]	A
[all declarations processed]	A

Element Information ItemElement Information Item

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

Attribute Information ItemAttribute Information Item

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

Processing Instruction Information ItemProcessing Instruction Information Item

the item itself	A
[target]	A
[content]	A
[base URI]	A
[notation]	X
[parent]	A

Unexpanded Entity Reference Information ItemUnexpanded Entity Reference Information Item

Note:

This type of information item will not occur at all if standalone="yes"

the item itself	B'
all properties	B'

Character Information ItemCharacter Information Item

the item itself	A
[character code]	A
[element content whitespace]	V
[parent]	A

Comment Information ItemComment Information Item

the item itself	A
[content]	A
[parent]	A

Document Type Declaration Information ItemDocument Type Declaration Information Item

the item itself	X
all properties	X

Unparsed Entity Information ItemUnparsed Entity Information Item

the item itself	B, P
all properties	B, P

Notation Information ItemNotation Information Item

the item itself	B, P
all properties	B, P

Namespace Information ItemNamespace Information Item

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

4 Invariants

Data models constructed in conformance with one of the profiles defined above will be guaranteed to share certain properties. The following sub-sections describe this in terms of invariants with respect to the information available in the data model.

5 Other profiles (non-normative)

The profiles defined here, particularly the 2.4 The recommended XML processor profile, 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.4 The recommended XML processor profile.

6 Conformance

Conformance is a matter for any specification which references this one to mandate, expressed in terms such as "Conforming implementations must construct input data models from XML documents as required by the recommended XML processor profile."