Status of This Document
This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in theW3C technical reports indexat http://www.w3.org/TR/.
This document is a product of theXML Core Working Groupas part of theW3C XML Activity.The English version of this specification is the only normative version. However, for translations of this document, seehttp://www.w3.org/2003/03/Translations/byTechnology?technology=xml-stylesheet.
This second edition incorporates all known errata as of the publication date,clarifies several areas left unspecified in the earlier edition, and has beenrestructured to allow other specifications to reuse the rules for parsing pseudo-attributes from a string. A more detailed descriptionof the changes from the first edition is inB Changes since the first edition.This edition supersedes the previousedition of 29June 1999.
Comments on this document may be sent towww-xml-stylesheet-comments@w3.org;publicarchivesare available. The errata list for this document is available athttp://www.w3.org/1999/06/REC-xml-stylesheet-19990629/errata
This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.
W3C maintains apubliclist of any patent disclosuresmade in connection with the deliverables ofthe group; that page also includes instructions for disclosing a patent.An individual who has actual knowledge of a patent which the individualbelieves containsEssentialClaim(s)must disclose the information in accordance withsection6 of the W3C Patent Policy.
1 Introduction
(This section is non-normative.)
Authors might have particular intentions as to howuser agents are to present the information contained in their XML documents. This specification provides a non-intrusive mechanism, using a processinginstruction, to provide links to one or more style sheets, i.e. resourcesspecifying the desired rendering in a designated language. Useragents will use these resources to control presentation of XML.
Consider an XHTML document with style sheet associations using thelink element:
<html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Example with link elements</title> <link rel="stylesheet" href="common.css"/> <link rel="stylesheet" href="default.css" title="Default style"/> <link rel="alternate stylesheet" href="alt.css" title="Alternative style"/> <link rel="stylesheet" href="single-col.css" media="all and (max-width: 30em)"/> </head> <body> ... </body></html>
This document could be written as follows, usingxml-stylesheet processing instructions:
<?xml-stylesheet href="common.css"?><?xml-stylesheet href="default.css" title="Default style"?><?xml-stylesheet alternate="yes" href="alt.css" title="Alternative style"?><?xml-stylesheet href="single-col.css" media="all and (max-width: 30em)"?><html xmlns="http://www.w3.org/1999/xhtml"> <head> <title>Example with xml-stylesheet processing instructions</title> </head> <body> ... </body></html>
2 Conformance requirements
All diagrams, examples, and notes in this specification arenon-normative, as are all sections explicitly marked non-normative.Everything else in this specification is normative.
The key wordsmust,mustnot,should,should not andmay in the normative partsof this document are to be interpreted as described in RFC 2119. These words do not appear in all uppercase letters inthis specification.[RFC2119]
The following conformance classes are defined by this specification:
- Documents
A document is considered to be a conforming document if it satisfies allmust-level criteria in this specification that apply to documents.
xml-stylesheetprocessing instructions and their pseudo-attributes are intended foruse by document authors to provide links to and information about one or more stylesheets, as described in4 The xml-stylesheet processing instruction, which areavailable to be applied to the containing document.
- xml-stylesheet processors
XML defines anapplication as a software module which receives the information content of an XML document from anXML processor. [Definition: Anxml-stylesheet processor is such an application which processes XMLprocessing instructions in accordance with this specification.][XML]
Anxml-stylesheet processor is considered to be a conformingxml-stylesheet processor if it satisfies allmust-level criteria in this specification that apply toxml-stylesheet processors.xml-stylesheet processors do not have to check or enforce any of the constraints on documents.
- Applications
Anxml-stylesheet processormay be part of a larger XML application, ormay function independently. In either case, [Definition: anapplication is the consumer of the pseudo-attribute analysis defined in this specification.]
A detailed specification of howapplications exploit the information contained inxml-stylesheetprocessing instructions is out of scope for this document, as this may reasonably vary from application to application. Accordingly this specification places no conformance requirements on applications.
It is however expected that specifications governing the use of stylesheet languages will reference this specification in describing how applications may identify stylesheets for use. Such specifications are expected to specify interpretations for the values (or absense of value) of thosepseudo-attributes which they make use of, doing so in a way that is as consistent as possible with thosepseudo-attributes' descriptions in4 The xml-stylesheet processing instruction, insofar as this makes sense for the application and stylesheet language(s) in question.
This specification is defined with reference to the vocabulary for XML provided by the XML Information Set.[INFOSET]
The productions in this specification use the same notation as used in the XML specification. Tokens in the grammar that are not defined in this specification are defined in the XML specification.[XML]
4 The xml-stylesheet processing instruction
[Definition: A processing instruction information item is said to be apotential xml-stylesheet processing instruction if it has the [target] propertyxml-stylesheet and it either is in the [children] property of a document information item and appears before the element information item of the document information item's [children] property, or it appears in the [children] property of a document type declaration information item.]
Forpotential xml-stylesheet processing instructions that are in the [children] property of a document information item,xml-stylesheet processorsmust report to theapplication theparsing result of invoking therules for parsing pseudo-attributes from a string, using the processing instruction information item's [content] property as the string.
Forpotentialxml-stylesheet processing instructions that are in the [children] property of a document type declaration information item,xml-stylesheet processorsmay report to theapplication theparsing result of invoking therules for parsing pseudo-attributes from a string, using the processing instruction information item's [content] property as the string. [Definition: If it is not reported to theapplication, the processing instruction information item is said to beignored.]
Note:
Since non-validating XML processors are not required to read parameter entities or the external subset, it is possible that processing instructions that appear in parameter entities or the external subset will not be present in the document type declaration information item's [children] property.[XML]
[Definition: Apotential xml-stylesheet processing instruction is said to be anxml-stylesheet processing instruction if theparsing result is not an error when invoking therules for parsing pseudo-attributes from a string, using the processing instruction information item's [content] property as the string.]
Documentsmust not use processing instruction information items with the [target] propertyxml-stylesheet if they are notxml-stylesheet processing instructions.
Documentsshould not usexml-stylesheet processing instructions that are in the [children] property of a document type declaration information item.
Anxml-stylesheet processing instruction will match the following production:
Production for xml-stylesheet processing instruction
Documentsmay specify the followingpseudo-attributes onxml-stylesheet processing instructions, unless otherwise stated:
hrefGives the address of the referenced style sheet. Documentsmust specify thispseudo-attribute. Documentsmust set thevalue to a string that matches the grammar for<IRI-reference> given in RFC 3987.[RFC3987]
typeGives an advisory media type for the referenced style sheet. Ifspecified, documentsmust set thevalue to a string that matches themedia-type production defined in section 3.7 "Media Types"of RFC 2616.[RFC2616]
Note:
Syntactic conformance to theproduction in RFC 2616 is all that is required by the above. Thisspecification imposes no requirements with respect to the status of the typesused. Some unregistered (as of the publication of this specification) mediatypes, such astext/xsl, are well-supported by existingimplementations, whereas some registered media types, such asapplication/xslt+xml, are not.
Thevalue is advisory inthat it is intended to be used by an application only when no other source ofmedia typeinformation becomes available during retrieval of the stylesheet itself.
titleGives the title of the referenced style sheet in a style sheetset. No constraints beyond those of thePseudoAttValue productionare placed on thevalue.
mediaGives the media for which the referenced style sheet applies. Ifspecified, documentsmust set thevalue to a string that matches themedia_query_list production of the Media Queries specification.[MQ]
charsetGives an advisory character encoding for the referenced stylesheet. If specified, documentsmust set thevalue to a validcharacter encoding name, whichmust be the name or alias labeled as "preferred MIME name" in the IANA Character Sets registry, if there is one, or the encoding's name, if none of the aliases are so labeled.[IANACHARSET]
Thevalue is advisory inthat it is intended to be used by an application only when no other source of encodinginformation becomes available during retrieval of the stylesheet itself, either explicitly via an HTTP header,or implicitly via its media type, as in the case of XML documents.
alternateIf thevalue is "yes", itindicates that the referenced style sheet is an alternative stylesheet, and documentsmust also specify thetitlepseudo-attribute with a non-emptyvalue. If specified, documentsmust set thevalue to either "yes" or"no".
Documentsmust not specify otherpseudo-attributes onxml-stylesheet processing instructions.
Any links to style sheets that are specified externally to thedocument (e.g.Link headers in some versions of HTTP[RFC2068]) are considered to create associations that occur before the associations specified by thexml-stylesheet processing instructions. Theapplication is responsible for taking all associations and determining how, if at all, their order affects its processing.
A References
References are normative unless marked "non-normative".
- IANACHARSET
- Character Sets. IANA, May 2007. (See http://www.iana.org/assignments/character-sets.)
- INFOSET
- XML Information Set, J. Cowan, R. Tobin. W3C, February 2004. (See http://www.w3.org/TR/xml-infoset/.)
- MQ
- Media Queries, H. Lie, T. Çelik, D. Glazman, A. van Kesteren. W3C, April 2009. (See http://www.w3.org/TR/css3-mediaqueries/.)
- RFC2068
- (non-normative)Hypertext Transfer Protocol — HTTP/1.1, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee. IETF, June 1997. (See http://www.ietf.org/rfc/rfc2068.txt.)
- RFC2119
- Key words for use in RFCs to Indicate Requirement Levels, S. Bradner. IETF, March 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)
- RFC2616
- Hypertext Transfer Protocol — HTTP/1.1, R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach, T. Berners-Lee. IETF, June 1999. (See http://www.ietf.org/rfc/rfc2616.txt.)
- RFC3987
- Internationalized Resource Identifiers (IRIs), M. Dürst, M. Suignard. IETF, January 2005. (See http://www.ietf.org/rfc/rfc3987.txt.)
- XML
- Extensible Markup Language, T. Bray, J. Paoli, C. Sperberg-McQueen, E. Maler, F. Yergeau. W3C, November 2008. (See http://www.w3.org/TR/xml/.)
- XSLT
- (non-normative)XSL Transformations (XSLT) Version 2.0, M. Kay. W3C, January 2007. (See http://www.w3.org/TR/xslt20/.)
B Changes since the first edition
This appendix is non-normative
The first edition of this specification was admirably brief, but at thesame time left many details unstated. This second edition aims to fill thegaps left in the first edition, while restructuring the presentation to providefor independent citation and re-use of the pseudo-attribute construct.
Neither the syntax nor the semantics of thexml-stylesheetprocessing instructions have been changed, beyond the restructuring justmentioned. Conformance constraints on processors have been eased slightly, inthatxml-stylesheetprocessing instructions occurring within the internal or external subset may be ignored.
The following list identifies the major changes which have been made:
Provided definitions for a number of terms used but not defined in thefirst edition;
Added a conformance section, distinguishing between processorand document conformance, all of which was implicit in the first edition;
Identified a number of error cases, which were implicit in the firstedition's appeal to the parallel with element start tag processing, andspecified expected processor behaviour;
In recognition of deployed processor behaviour, allowedxml-stylesheet processing instructions to be ignored unless theyare among the [children] of the document information item;
Added a number of references, but removed the explicitdependence on the HTML 4.0 specification by adding descriptions of the meaningsof each of the pseudo-attributes consistent with their HTML 4.0 use but brought up-to-date;
Removed the (non-normative) Rationale section, as it contained anumber of out-of-date assumptions;
Made thetype pseudo-attribute optional, as agreedbyexisting erratum.