This specification is defined in terms of the XML Information Set. [INFOSET]
For readability, the words "information item" have been left out, and the brackets around an information item's properties have also been left out. For example, the phrase "a processing instruction information item's [content]" just reads "a processing instruction's content".
All diagrams, examples, and notes in this specification are non-normative, as are all sections explicitly marked non-normative. Everything else in this specification is normative.
The key words "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in the normative parts of this document are to be interpreted as described in RFC2119. For readability, these words do not appear in all uppercase letters in this specification. [RFC2119]
The grammar used in this specification is using the same notation as the grammar in the XML specification. Symbols in the grammar that are not defined in this specification are defined in the XML specification. [XML]
There are the following conformance classes of this specification:
User agents must act as described in this specification. It is expected that this specification will be implemented on a layer between the XML processor and the application, so that an "xml-stylesheet processor" acts upon a processing instruction's content, and passes on the pseudo-attributes to the application for further processing; however, this specification may be implemented in any manner so long as the end result is equivalent.
A document that follows all appliciable requirements on documents in this specification is a conforming document. Authors, authoring tools and markup generators must produce conforming documents.
Conformance checkers must verify that an XML document being checked is a conforming document. Conformance checkers may check for further constraints defined by other specifications (see below).
This specification does not define processing requirements for each pseudo-attribute. It is expected that these will be different for different style sheet languages, and hence, it is expected that style sheet languages using this specification define those processing requirements. Specification authors are adviced that the semantics of the pseudo-attributes are intended to be equivalent to the attributes of the same names on
<link rel="stylesheet"> in HTML, or, when the
alternate="yes" pseudo-attribute is specified,
<link rel="alternate stylesheet">. [HTML] Specifications may define that some pseudo-attributes are ignored altogether and are not allowed to be specified for that style sheet language.
This specification separates the parsing rules for processing instructions with pseudo-attributes from the rules specific to
xml-stylesheet processing instructions, so that other specifications can use the same parsing rules for other processing instructions. Such specifications must not modify the parsing rules defined in this specification.
Certain processing instructions are said to be processing instructions with pseudo-attributes. The content of such a processing instruction must match the
PIContent production below. If it does not, user agents must ignore the processing instruction.
PseudoAtt symbol represents a pseudo-attribute. A pseudo-attribute has a name and a value. The
Name symbol represents the name of a pseudo-attribute. The
PseudoAttValue symbol, after
PredefEntityRef are replaced with the characters they represent, represent the value of a pseudo-attribute.
There must not be more than one pseudo-attribute with the same name. If there are, user agents must ignore the processing instruction.
PICharRef has the same semantics as a
CharRef in XML, except that Legal Character is not a well-formedness constraint. User agents must replace the
PICharRef in the pseudo-attribute's value with the character it represents according to XML had it been a
CharRef, except if the character being referred does not match the production for
Char in XML, in which case the processing instruction must be ignored. [XML]
User agents must replace
PredefEntityRef in the pseudo-attribute's value with U+0026 (
&) if it was "
&", U+003C (
<) if it was "
<", U+003E (
>) if it was "
>", U+0022 (
") if it was "
"" and U+0027 (
') if it was "
A processing instruction that is a child of a document but does not appear after the element child of the document and has the target "
xml-stylesheet" is a processing instruction with pseudo-attributes, and is said to be an
xml-stylesheet processing instruction unless parsing caused it to be ignored. A processing instruction with the target "
xml-stylesheet" must not be a child of an element and must not appear after the element child of a document.
xml-stylesheet processing instruction will match the following production:
The following pseudo-attributes may be specified on
xml-stylesheet processing instructions, unless otherwise stated by another specification:
Gives the address of the referenced style sheet. This pseudo-attribute must be specified. The value must match the grammar for <IRI-reference> given in RFC 3987. [RFC3987]
Gives an advisory type of the referenced style sheet. If specified, the value must match the
media-type token defined in section 3.7 "Media Types" of RFC 2616. [HTTP]
Gives the title of the referenced style sheet in a style sheet set. If specified, the value may be any string.
Gives the media for which the referenced style sheet applies. If specified, the value must be a valid Media Query. [MQ]
Gives an advisory character encoding for the referenced style sheet. If specified, the value must be a valid character encoding name, and must be the preferred name for that encoding. [IANACHARSET]
If the value is "
yes", it indicates that the referenced style sheet is an alternative style sheet, and the
title pseudo-attribute must also be specified with a non-empty value. If specified, the value must be either "
yes" or "
Other pseudo-attributes must not be specified on
xml-stylesheet processing instructions. User agents must ignore other pseudo-attributes.