You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1598 lines
220 KiB
1598 lines
220 KiB
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html lang="EN" xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html;charset=UTF-8" /><title>Extensible Markup Language (XML) 1.1</title><style type="text/css">
|
|
code { font-family: monospace; }
|
|
|
|
div.constraint,
|
|
div.issue,
|
|
div.note,
|
|
div.notice { margin-left: 2em; }
|
|
|
|
li p { margin-top: 0.3em;
|
|
margin-bottom: 0.3em; }
|
|
|
|
div.exampleInner pre { margin-left: 1em;
|
|
margin-top: 0em; margin-bottom: 0em}
|
|
div.exampleOuter {border: 4px double gray;
|
|
margin: 0em; padding: 0em}
|
|
div.exampleInner { background-color: #d5dee3;
|
|
border-top-width: 4px;
|
|
border-top-style: double;
|
|
border-top-color: #d3d3d3;
|
|
border-bottom-width: 4px;
|
|
border-bottom-style: double;
|
|
border-bottom-color: #d3d3d3;
|
|
padding: 4px; margin: 0em }
|
|
div.exampleWrapper { margin: 4px }
|
|
div.exampleHeader { font-weight: bold;
|
|
margin: 4px}
|
|
|
|
em.rfc2119 { text-transform: lowercase;
|
|
font-variant: small-caps;
|
|
font-style: normal; }
|
|
</style><link rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-REC.css" /></head><body><div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72" /></a></p>
|
|
<h1><a name="title" id="title" />Extensible Markup Language (XML) 1.1</h1>
|
|
<h2><a name="w3c-doctype" id="w3c-doctype" />W3C Recommendation 04
|
|
February 2004, edited in place 15 April 2004</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2004/REC-xml11-20040204/">http://www.w3.org/TR/2004/REC-xml11-20040204/</a></dd><dt>Latest version:</dt><dd><a href="http://www.w3.org/TR/xml11">http://www.w3.org/TR/xml11</a></dd><dt>Previous version:</dt><dd><a href="http://www.w3.org/TR/2003/PR-xml11-20031105/">http://www.w3.org/TR/2003/PR-xml11-20031105/</a></dd><dt>Editors:</dt><dd>Tim Bray, Textuality and Netscape <a href="mailto:tbray@textuality.com"><tbray@textuality.com></a></dd><dd>Jean Paoli, Microsoft <a href="mailto:jeanpa@microsoft.com"><jeanpa@microsoft.com></a></dd><dd>C. M. Sperberg-McQueen, W3C <a href="mailto:cmsmcq@w3.org"><cmsmcq@w3.org></a></dd><dd>Eve Maler, Sun Microsystems, Inc. <a href="mailto:elm@east.sun.com"><eve.maler@east.sun.com></a></dd><dd>François Yergeau <a href="mailto:fyergeau@alis.com"><fyergeau@alis.com></a></dd><dd>John Cowan <a href="mailto:cowan@ccil.org"><cowan@ccil.org></a></dd></dl><p>Please refer to the <a href="http://www.w3.org/XML/xml-V11-1e-errata"><strong>errata</strong></a> for this document, which may include some normative corrections.</p><p>This document is also available in these non-normative formats: <a href="REC-xml11-20040204.xml">XML</a> and <a href="REC-xml11-20040204-review.html">XHTML with color-coded revision indicators</a>.</p><p>See also <a href="http://www.w3.org/2003/03/Translations/byTechnology?technology=xml11"><strong>translations</strong></a>.</p><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2004 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>, <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software">software licensing</a> rules apply.</p></div><hr /><div> <h2><a name="abstract" id="abstract" />Abstract</h2><p>The Extensible Markup Language (XML) is a subset of SGML that is completely
|
|
described in this document. Its goal is to enable generic SGML to be served,
|
|
received, and processed on the Web in the way that is now possible with HTML.
|
|
XML has been designed for ease of implementation and for interoperability
|
|
with both SGML and HTML.</p></div><div> <h2><a name="status" id="status" />Status of this Document</h2><p><em>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 the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p><p>This document is a <a href="http://www.w3.org/2003/06/Process-20030618/tr.html#RecsW3C">Recommendation</a> of the W3C.
|
|
It has been reviewed by W3C Members and other interested parties, and has
|
|
been endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited as a normative reference 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.</p><p>This document specifies a syntax created by subsetting an existing, widely
|
|
used international text processing standard (Standard Generalized Markup Language,
|
|
ISO 8879:1986(E) as amended and corrected) for use on the World Wide Web.
|
|
It is a product of the <a
|
|
href="http://www.w3.org/XML/Activity.html">W3C XML
|
|
Activity</a>.</p>
|
|
|
|
<p>On 15 April 2004, this document was edited in place to add two
|
|
missing spaces to <a
|
|
href="http://www.w3.org/TR/2004/REC-xml11-20040204/Overview.html#NT-document">production
|
|
[1]</a> in section 2.1</p>
|
|
|
|
<p>The English version of this specification is the only normative version. However,
|
|
for translations of this document, see <a href="http://www.w3.org/2003/03/Translations/byTechnology?technology=xml11">http://www.w3.org/2003/03/Translations/byTechnology?technology=xml11</a>.
|
|
</p><p>Documentation of intellectual property possibly relevant to this recommendation
|
|
may be found at the Working Group's public
|
|
<a href="http://www.w3.org/2002/08/xmlcore-IPR-statements">IPR disclosure page</a>.</p><p>An implementation report for XML 1.1 is available at <a href="http://www.w3.org/XML/2002/09/xml11-implementation.html">http://www.w3.org/XML/2002/09/xml11-implementation.html</a>.</p><p>Please report errors in this document to <a href="mailto:xml-editor@w3.org">xml-editor@w3.org</a>; <a href="http://lists.w3.org/Archives/Public/xml-editor">archives</a> are available. The errata list for this edition is available
|
|
at <a href="http://www.w3.org/XML/xml-V11-1e-errata">http://www.w3.org/XML/xml-V11-1e-errata</a>.</p><p>A <a href="http://www.w3.org/XML/Test/">Test Suite</a> is maintained to help assessing conformance to this specification.</p></div><div class="toc"> <h2><a name="contents" id="contents" />Table of Contents</h2><p class="toc">1 <a href="#sec-intro">Introduction</a><br /> 1.1 <a href="#sec-origin-goals">Origin and Goals</a><br /> 1.2 <a href="#sec-terminology">Terminology</a><br /> 1.3 <a href="#sec-xml11">Rationale and list of changes for XML 1.1</a><br /> 2 <a href="#sec-documents">Documents</a><br /> 2.1 <a href="#sec-well-formed">Well-Formed XML Documents</a><br /> 2.2 <a href="#charsets">Characters</a><br /> 2.3 <a href="#sec-common-syn">Common Syntactic Constructs</a><br /> 2.4 <a href="#syntax">Character Data and Markup</a><br /> 2.5 <a href="#sec-comments">Comments</a><br /> 2.6 <a href="#sec-pi">Processing Instructions</a><br /> 2.7 <a href="#sec-cdata-sect">CDATA Sections</a><br /> 2.8 <a href="#sec-prolog-dtd">Prolog and Document Type Declaration</a><br /> 2.9 <a href="#sec-rmd">Standalone Document Declaration</a><br /> 2.10 <a href="#sec-white-space">White Space Handling</a><br /> 2.11 <a href="#sec-line-ends">End-of-Line Handling</a><br /> 2.12 <a href="#sec-lang-tag">Language Identification</a><br /> 2.13 <a href="#sec-normalization-checking">Normalization Checking</a><br /> 3 <a href="#sec-logical-struct">Logical Structures</a><br /> 3.1 <a href="#sec-starttags">Start-Tags, End-Tags, and Empty-Element Tags</a><br /> 3.2 <a href="#elemdecls">Element Type Declarations</a><br /> 3.2.1 <a href="#sec-element-content">Element Content</a><br /> 3.2.2 <a href="#sec-mixed-content">Mixed Content</a><br /> 3.3 <a href="#attdecls">Attribute-List Declarations</a><br /> 3.3.1 <a href="#sec-attribute-types">Attribute Types</a><br /> 3.3.2 <a href="#sec-attr-defaults">Attribute Defaults</a><br /> 3.3.3 <a href="#AVNormalize">Attribute-Value Normalization</a><br /> 3.4 <a href="#sec-condition-sect">Conditional Sections</a><br /> 4 <a href="#sec-physical-struct">Physical Structures</a><br /> 4.1 <a href="#sec-references">Character and Entity References</a><br /> 4.2 <a href="#sec-entity-decl">Entity Declarations</a><br /> 4.2.1 <a href="#sec-internal-ent">Internal Entities</a><br /> 4.2.2 <a href="#sec-external-ent">External Entities</a><br /> 4.3 <a href="#TextEntities">Parsed Entities</a><br /> 4.3.1 <a href="#sec-TextDecl">The Text Declaration</a><br /> 4.3.2 <a href="#wf-entities">Well-Formed Parsed Entities</a><br /> 4.3.3 <a href="#charencoding">Character Encoding in Entities</a><br /> 4.3.4 <a href="#sec-version-info">Version Information in Entities</a><br /> 4.4 <a href="#entproc">XML Processor Treatment of Entities and References</a><br /> 4.4.1 <a href="#not-recognized">Not Recognized</a><br /> 4.4.2 <a href="#included">Included</a><br /> 4.4.3 <a href="#include-if-valid">Included If Validating</a><br /> 4.4.4 <a href="#forbidden">Forbidden</a><br /> 4.4.5 <a href="#inliteral">Included in Literal</a><br /> 4.4.6 <a href="#notify">Notify</a><br /> 4.4.7 <a href="#bypass">Bypassed</a><br /> 4.4.8 <a href="#as-PE">Included as PE</a><br /> 4.4.9 <a href="#error">Error</a><br /> 4.5 <a href="#intern-replacement">Construction of Entity Replacement Text</a><br /> 4.6 <a href="#sec-predefined-ent">Predefined Entities</a><br /> 4.7 <a href="#Notations">Notation Declarations</a><br /> 4.8 <a href="#sec-doc-entity">Document Entity</a><br /> 5 <a href="#sec-conformance">Conformance</a><br /> 5.1 <a href="#proc-types">Validating and Non-Validating Processors</a><br /> 5.2 <a href="#safe-behavior">Using XML Processors</a><br /> 6 <a href="#sec-notation">Notation</a><br /> </p> <h3><a name="appendices" id="appendices" />Appendices</h3><p class="toc">A <a href="#sec-bibliography">References</a><br /> A.1 <a href="#sec-existing-stds">Normative References</a><br /> A.2 <a href="#null">Other References</a><br /> B <a href="#sec-CharNorm">Definitions for Character Normalization</a><br /> C <a href="#sec-entexpand">Expansion of Entity and Character References</a> (Non-Normative)<br /> D <a href="#determinism">Deterministic Content Models</a> (Non-Normative)<br /> E <a href="#sec-guessing">Autodetection of Character Encodings</a> (Non-Normative)<br /> E.1 <a href="#sec-guessing-no-ext-info">Detection Without External Encoding Information</a><br /> E.2 <a href="#sec-guessing-with-ext-info">Priorities in the Presence of External Encoding Information</a><br /> F <a href="#sec-xml-wg">W3C XML Working Group</a> (Non-Normative)<br /> G <a href="#sec-core-wg">W3C XML Core Working Group</a> (Non-Normative)<br /> H <a href="#prod-notes">Production Notes</a> (Non-Normative)<br /> I <a href="#sec-suggested-names">Suggestions for XML Names</a> (Non-Normative)<br /> </p></div><hr /><div class="body"><div class="div1"> <h2><a name="sec-intro" id="sec-intro" />1 Introduction</h2><p>Extensible Markup Language, abbreviated XML, describes a class of data
|
|
objects called <a title="XML Document" href="#dt-xml-doc">XML documents</a> and partially
|
|
describes the behavior of computer programs which process them. XML is an
|
|
application profile or restricted form of SGML, the Standard Generalized Markup
|
|
Language <a href="#ISO8879">[ISO 8879]</a>. By construction, XML documents are conforming
|
|
SGML documents.</p><p>XML documents are made up of storage units called <a title="Entity" href="#dt-entity">entities</a>,
|
|
which contain either parsed or unparsed data. Parsed data is made up of <a title="Character" href="#dt-character">characters</a>, some of which form <a title="Character Data" href="#dt-chardata">character
|
|
data</a>, and some of which form <a title="Markup" href="#dt-markup">markup</a>.
|
|
Markup encodes a description of the document's storage layout and logical
|
|
structure. XML provides a mechanism to impose constraints on the storage layout
|
|
and logical structure.</p><p>[<a name="dt-xml-proc" id="dt-xml-proc" title="XML Processor">Definition</a>: A software module called
|
|
an <b>XML processor</b> is used to read XML documents and provide access
|
|
to their content and structure.] [<a name="dt-app" id="dt-app" title="Application">Definition</a>: It
|
|
is assumed that an XML processor is doing its work on behalf of another module,
|
|
called the <b>application</b>.] This specification describes
|
|
the required behavior of an XML processor in terms of how it must read XML
|
|
data and the information it must provide to the application.</p><div class="div2"> <h3><a name="sec-origin-goals" id="sec-origin-goals" />1.1 Origin and Goals</h3><p>XML was developed by an XML Working Group (originally known as the SGML
|
|
Editorial Review Board) formed under the auspices of the World Wide Web Consortium
|
|
(W3C) in 1996. It was chaired by Jon Bosak of Sun Microsystems with the active
|
|
participation of an XML Special Interest Group (previously known as the SGML
|
|
Working Group) also organized by the W3C. The membership of the XML Working
|
|
Group is given in an appendix. Dan Connolly served as the Working Group's contact with
|
|
the W3C.</p><p>The design goals for XML are:</p><ol type="1"><li><p>XML shall be straightforwardly usable over the Internet.</p></li><li><p>XML shall support a wide variety of applications.</p></li><li><p>XML shall be compatible with SGML.</p></li><li><p>It shall be easy to write programs which process XML documents.</p></li><li><p>The number of optional features in XML is to be kept to the absolute
|
|
minimum, ideally zero.</p></li><li><p>XML documents should be human-legible and reasonably clear.</p></li><li><p>The XML design should be prepared quickly.</p></li><li><p>The design of XML shall be formal and concise.</p></li><li><p>XML documents shall be easy to create.</p></li><li><p>Terseness in XML markup is of minimal importance.</p></li></ol><p>This specification, together with associated standards (Unicode
|
|
<a href="#Unicode">[Unicode]</a> and ISO/IEC 10646 <a href="#ISO10646">[ISO/IEC 10646]</a>
|
|
for characters, Internet RFC 3066 <a href="#RFC1766">[IETF RFC 3066]</a> for
|
|
language identification tags, ISO 639 <a href="#ISO639">[ISO 639]</a>
|
|
for language name codes, and ISO 3166 <a href="#ISO3166">[ISO 3166]</a> for
|
|
country name codes), provides all the information necessary to
|
|
understand XML Version 1.1 and construct computer
|
|
programs to process it.</p><p>This version of the XML specification may be distributed freely, as long as
|
|
all text and legal notices remain intact.</p></div><div class="div2"> <h3><a name="sec-terminology" id="sec-terminology" />1.2 Terminology</h3><p>The terminology used to describe XML documents is defined in the body of
|
|
this specification. <span class="mustard">The key words <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em>, <em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em>, <em class="rfc2119" title="Keyword in RFC 2119 context">REQUIRED</em>, <em class="rfc2119" title="Keyword in RFC 2119 context">SHALL</em>, <em class="rfc2119" title="Keyword in RFC 2119 context">SHALL NOT</em>, <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em>, <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD NOT</em>, <em class="rfc2119" title="Keyword in RFC 2119 context">RECOMMENDED</em>, <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em>, and <em class="rfc2119" title="Keyword in RFC 2119 context">OPTIONAL</em>, when <em class="rfc2119" title="Keyword in RFC 2119 context">EMPHASIZED</em>, are to be interpreted as described in <a href="#rfc2119">[IETF RFC 2119]</a>. In addition, </span>the terms defined in the following list are used in building
|
|
those definitions and in describing the actions of an XML processor:</p><dl><dt class="label">error</dt><dd><p>[<a name="dt-error" id="dt-error" title="Error">Definition</a>: A violation of the rules of this specification;
|
|
results are undefined. <span class="mustard">Unless otherwise specified, failure to observe a prescription of this specification indicated by one of the keywords <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em>, <em class="rfc2119" title="Keyword in RFC 2119 context">REQUIRED</em>, <em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em>, <em class="rfc2119" title="Keyword in RFC 2119 context">SHALL</em> and <em class="rfc2119" title="Keyword in RFC 2119 context">SHALL NOT</em> is an error.</span> Conforming software <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> detect and report an error
|
|
and <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> recover from it.]</p></dd><dt class="label">fatal error</dt><dd><p>[<a name="dt-fatal" id="dt-fatal" title="Fatal Error">Definition</a>: An error which a conforming <a title="XML Processor" href="#dt-xml-proc">XML processor</a> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> detect and report to the application.
|
|
After encountering a fatal error, the processor <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> continue processing the
|
|
data to search for further errors and <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> report such errors to the application.
|
|
In order to support correction of errors, the processor <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> make unprocessed
|
|
data from the document (with intermingled character data and markup) available
|
|
to the application. Once a fatal error is detected, however, the processor
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em> continue normal processing (i.e., it <em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em> continue to pass character
|
|
data and information about the document's logical structure to the application
|
|
in the normal way).]</p></dd><dt class="label">at user option</dt><dd><p>[<a name="dt-atuseroption" id="dt-atuseroption" title="At user option">Definition</a>: Conforming software
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> or <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> (depending on the modal verb in the sentence) behave as described;
|
|
if it does, it <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> provide users a means to enable or disable the behavior
|
|
described.]</p></dd><dt class="label">validity constraint</dt><dd><p>[<a name="dt-vc" id="dt-vc" title="Validity constraint">Definition</a>: A rule which applies to
|
|
all <a title="Validity" href="#dt-valid">valid</a> XML documents. Violations of validity
|
|
constraints are errors; they <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em>, at user option, be reported by <a title="Validating Processor" href="#dt-validating">validating XML processors</a>.]</p></dd><dt class="label">well-formedness constraint</dt><dd><p>[<a name="dt-wfc" id="dt-wfc" title="Well-formedness constraint">Definition</a>: A rule which applies
|
|
to all <a title="Well-Formed" href="#dt-wellformed">well-formed</a> XML documents. Violations
|
|
of well-formedness constraints are <a title="Fatal Error" href="#dt-fatal">fatal errors</a>.]</p></dd><dt class="label">match</dt><dd><p>[<a name="dt-match" id="dt-match" title="match">Definition</a>: (Of strings or names:) Two strings
|
|
or names being compared <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be identical. Characters with multiple possible
|
|
representations in Unicode (e.g. characters with both precomposed and
|
|
base+diacritic forms) match only if they have the same representation in both
|
|
strings. No
|
|
case folding is performed. (Of strings and rules in the grammar:) A string
|
|
matches a grammatical production if it belongs to the language generated by
|
|
that production. (Of content and content models:) An element matches its declaration
|
|
when it conforms in the fashion described in the constraint <b>[VC: <a href="#elementvalid">Element Valid</a>]</b>.]</p></dd><dt class="label">for compatibility</dt><dd><p>[<a name="dt-compat" id="dt-compat" title="For Compatibility">Definition</a>: Marks
|
|
a sentence describing a feature of XML included solely to ensure
|
|
that XML remains compatible with SGML.]</p></dd><dt class="label">for interoperability</dt><dd><p>[<a name="dt-interop" id="dt-interop" title="For interoperability">Definition</a>: Marks
|
|
a sentence describing a non-binding recommendation included to increase
|
|
the chances that XML documents can be processed by the existing installed
|
|
base of SGML processors which predate the WebSGML Adaptations Annex to ISO 8879.]</p></dd></dl><p></p></div><div class="div2"> <h3><a name="sec-xml11" id="sec-xml11" />1.3 Rationale and list of changes for XML 1.1</h3><p>The W3C's XML 1.0 Recommendation was first issued in 1998, and
|
|
despite the issuance of many errata culminating in a Third Edition
|
|
of 2004, has remained (by intention) unchanged with respect to what
|
|
is well-formed XML and what is not. This stability has been
|
|
extremely useful for interoperability. However, the Unicode
|
|
Standard on which XML 1.0 relies for character specifications has
|
|
not remained static, evolving from version 2.0 to version 4.0 and
|
|
beyond. Characters not present in Unicode 2.0 may already be used
|
|
in XML 1.0 character data. However, they are not allowed in XML
|
|
names such as element type names, attribute names, enumerated
|
|
attribute values, processing instruction targets, and so on. In
|
|
addition, some characters that should have been permitted in XML
|
|
names were not, due to oversights and inconsistencies in Unicode
|
|
2.0.</p><p>The overall philosophy of names has changed since XML 1.0.
|
|
Whereas XML 1.0 provided a rigid definition of names, wherein
|
|
everything that was not permitted was forbidden, XML 1.1 names are
|
|
designed so that everything that is not forbidden (for a specific
|
|
reason) is permitted. Since Unicode will continue to grow past
|
|
version 4.0, further changes to XML can be avoided by allowing
|
|
almost any character, including those not yet assigned, in
|
|
names.</p><p>In addition, XML 1.0 attempts to adapt to the line-end
|
|
conventions of various modern operating systems, but discriminates
|
|
against the conventions used on IBM and IBM-compatible mainframes.
|
|
As a result, XML documents on mainframes are not plain text files
|
|
according to the local conventions. XML 1.0 documents generated on
|
|
mainframes must either violate the local line-end conventions, or
|
|
employ otherwise unnecessary translation phases before parsing and
|
|
after generation. Allowing straightforward interoperability is
|
|
particularly important when data stores are shared between
|
|
mainframe and non-mainframe systems (as opposed to being copied
|
|
from one to the other). Therefore XML 1.1 adds NEL (#x85) to the
|
|
list of line-end characters. For completeness, the Unicode line
|
|
separator character, #x2028, is also supported.
|
|
</p><p>Finally, there is considerable demand to define a standard representation
|
|
of arbitrary Unicode characters in XML documents. Therefore, XML 1.1
|
|
allows the use of character references to the control characters #x1 through
|
|
#x1F, most of which are forbidden in XML 1.0. For reasons of robustness,
|
|
however, these characters still cannot be used directly in documents. In
|
|
order to improve the robustness of character encoding detection, the additional
|
|
control characters #x7F through #x9F, which were freely allowed in XML 1.0
|
|
documents, now must also appear only as character references. (Whitespace
|
|
characters are of course exempt.) The minor sacrifice of backward compatibility
|
|
is considered not significant. Due to potential problems with APIs,
|
|
#x0 is still forbidden both directly and as a character reference.
|
|
</p><p>Finally, XML 1.1 defines a set of constraints called "full
|
|
normalization" on XML documents, which document creators
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> adhere to, and document processors
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> verify. Using fully normalized documents
|
|
ensures that identity comparisons of names, attribute values, and
|
|
character content can be made correctly by simple binary comparison of
|
|
Unicode strings.</p><p>A new XML version, rather than a set of errata to XML 1.0, is
|
|
being created because the changes affect the definition of
|
|
well-formed documents. XML 1.0 processors must continue to reject
|
|
documents that contain new characters in XML names, new line-end
|
|
conventions, and references to control characters. The distinction between XML 1.0 and XML 1.1 documents
|
|
is indicated by the version number information in the XML
|
|
declaration at the start of each document.
|
|
</p></div></div><div class="div1"> <h2><a name="sec-documents" id="sec-documents" />2 Documents</h2><p>[<a name="dt-xml-doc" id="dt-xml-doc" title="XML Document">Definition</a>: A data object is an <b>XML
|
|
document</b> if it is <a title="Well-Formed" href="#dt-wellformed">well-formed</a>,
|
|
as defined in this specification. A well-formed XML document <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> in addition
|
|
be <a title="Validity" href="#dt-valid">valid</a> if it meets certain further constraints.]</p><p>Each XML document has both a logical and a physical structure. Physically,
|
|
the document is composed of units called <a title="Entity" href="#dt-entity">entities</a>.
|
|
An entity <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> <a title="Entity Reference" href="#dt-entref">refer</a> to other entities to
|
|
cause their inclusion in the document. A document begins in a "root"
|
|
or <a title="Document Entity" href="#dt-docent">document entity</a>. Logically, the document
|
|
is composed of declarations, elements, comments, character references, and
|
|
processing instructions, all of which are indicated in the document by explicit
|
|
markup. The logical and physical structures <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> nest properly, as described
|
|
in <a href="#wf-entities"><b>4.3.2 Well-Formed Parsed Entities</b></a>.</p><div class="div2"> <h3><a name="sec-well-formed" id="sec-well-formed" />2.1 Well-Formed XML Documents</h3><p>[<a name="dt-wellformed" id="dt-wellformed" title="Well-Formed">Definition</a>: A textual object is a <b>well-formed</b>
|
|
XML document if:]</p><ol type="1"><li><p>Taken as a whole, it matches the production labeled <a href="#NT-document">document</a>.</p></li><li><p>It meets all the well-formedness constraints given in this specification.</p></li><li><p>Each of the <a title="Text Entity" href="#dt-parsedent">parsed entities</a>
|
|
which is referenced directly or indirectly within the document is <a
|
|
title="Well-Formed"
|
|
href="#dt-wellformed">well-formed</a>.</p></li></ol> <h5><a
|
|
name="document" id="document" />Document</h5><table class="scrap"
|
|
summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-document"
|
|
id="NT-document"
|
|
/>[1] </td><td><code>document</code></td><td> ::= </td><td><code><a
|
|
href="#NT-prolog">prolog</a> <a href="#NT-element">element</a> <a
|
|
href="#NT-Misc">Misc</a>* - <a href="#NT-Char">Char</a>* <a
|
|
href="#NT-RestrictedChar">RestrictedChar</a> <a href="#NT-Char">Char</a>*</code></td></tr></tbody></table><p>Matching the <a href="#NT-document">document</a> production implies that:</p><ol type="1"><li><p>It contains one or more <a title="Element" href="#dt-element">elements</a>.</p></li><li><p>[<a name="dt-root" id="dt-root" title="Root Element">Definition</a>: There is exactly one element,
|
|
called the <b>root</b>, or document element, no part of which appears
|
|
in the <a title="Content" href="#dt-content">content</a> of any other element.] For
|
|
all other elements, if the <a title="Start-Tag" href="#dt-stag">start-tag</a> is in
|
|
the content of another element, the <a title="End Tag" href="#dt-etag">end-tag</a>
|
|
is in the content of the same element. More simply stated, the elements,
|
|
delimited by start- and end-tags, nest properly within each other.</p></li></ol><p>[<a name="dt-parentchild" id="dt-parentchild" title="Parent/Child">Definition</a>: As a consequence of this,
|
|
for each non-root element <code>C</code> in the document, there is one other element <code>P</code>
|
|
in the document such that <code>C</code> is in the content of <code>P</code>, but
|
|
is not in the content of any other element that is in the content of <code>P</code>. <code>P</code>
|
|
is referred to as the <b>parent</b> of <code>C</code>, and <code>C</code> as
|
|
a <b>child</b> of <code>P</code>.]</p></div><div class="div2"> <h3><a name="charsets" id="charsets" />2.2 Characters</h3><p>[<a name="dt-text" id="dt-text" title="Text">Definition</a>: A parsed entity contains <b>text</b>,
|
|
a sequence of <a title="Character" href="#dt-character">characters</a>, which may
|
|
represent markup or character data.] [<a name="dt-character" id="dt-character" title="Character">Definition</a>: A <b>character</b>
|
|
is an atomic unit of text as specified by <span>ISO/IEC 10646 <a href="#ISO10646">[ISO/IEC 10646]</a></span>. Legal characters are tab, carriage
|
|
return, line feed, and the legal characters
|
|
of Unicode and ISO/IEC 10646. The
|
|
versions of these standards cited in <a href="#sec-existing-stds"><b>A.1 Normative References</b></a> were
|
|
current at the time this document was prepared. New characters may be added
|
|
to these standards by amendments or new editions. Consequently, XML processors
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> accept any character in the range specified for <a href="#NT-Char">Char</a>.]</p> <h5><a name="char32" id="char32" />Character Range</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-Char" id="NT-Char" />[2] </td><td><code>Char</code></td><td> ::= </td><td><code>[#x1-#xD7FF] | [#xE000-#xFFFD] | [#x10000-#x10FFFF]</code></td><td><i>/* any Unicode character, excluding the surrogate blocks, FFFE, and FFFF. */</i></td></tr><tr valign="baseline"><td><a name="NT-RestrictedChar" id="NT-RestrictedChar" />[2a] </td><td><code>RestrictedChar</code></td><td> ::= </td><td><code>[#x1-#x8] | [#xB-#xC] | [#xE-#x1F] | [#x7F-#x84] | [#x86-#x9F]</code></td></tr></tbody></table><p>The mechanism for encoding character code points into bit patterns <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em>
|
|
vary from entity to entity. All XML processors <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> accept the UTF-8 and UTF-16
|
|
encodings of <span> Unicode
|
|
<a href="#Unicode">[Unicode]</a></span>;
|
|
the mechanisms for signaling which of the two is in use,
|
|
or for bringing other encodings into play, are discussed later, in <a href="#charencoding"><b>4.3.3 Character Encoding in Entities</b></a>.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>Document authors are encouraged to avoid
|
|
"compatibility characters", as defined
|
|
in Unicode <a href="#Unicode">[Unicode]</a>.
|
|
The characters defined in the following ranges are also
|
|
discouraged. They are either control characters or permanently undefined Unicode
|
|
characters:</p><div class="exampleInner"><pre>
|
|
[#x7F-#x84], [#x86-#x9F], [#xFDD0-#xFDDF],
|
|
[#1FFFE-#x1FFFF], [#2FFFE-#x2FFFF], [#3FFFE-#x3FFFF],
|
|
[#4FFFE-#x4FFFF], [#5FFFE-#x5FFFF], [#6FFFE-#x6FFFF],
|
|
[#7FFFE-#x7FFFF], [#8FFFE-#x8FFFF], [#9FFFE-#x9FFFF],
|
|
[#AFFFE-#xAFFFF], [#BFFFE-#xBFFFF], [#CFFFE-#xCFFFF],
|
|
[#DFFFE-#xDFFFF], [#EFFFE-#xEFFFF], [#FFFFE-#xFFFFF],
|
|
[#10FFFE-#x10FFFF].</pre></div></div></div><div class="div2"> <h3><a name="sec-common-syn" id="sec-common-syn" />2.3 Common Syntactic Constructs</h3><p>This section defines some symbols used widely in the grammar.</p><p><a href="#NT-S">S</a> (white space) consists of one or more space (#x20)
|
|
characters, carriage returns, line feeds, or tabs.</p> <h5><a name="white" id="white" />White Space</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-S" id="NT-S" />[3] </td><td><code>S</code></td><td> ::= </td><td><code>(#x20 | #x9 | #xD | #xA)+</code></td></tr></tbody></table><div class="note"><p class="prefix"><b>Note:</b></p><p>The presence of #xD in the above production is
|
|
maintained purely for backward compatibility with the
|
|
<a href="http://www.w3.org/TR/1998/REC-xml-19980210">First Edition</a>.
|
|
As explained in <a href="#sec-line-ends"><b>2.11 End-of-Line Handling</b></a>,
|
|
all #xD characters literally present in an XML document
|
|
are either removed or replaced by #xA characters before
|
|
any other processing is done. The only way to get a #xD character to match this production is to
|
|
use a character reference in an entity value literal.</p></div><p>[<a name="dt-name" id="dt-name" title="Name">Definition</a>: A <b>Name</b> is a token beginning
|
|
with a letter or one of a few punctuation characters, and continuing with
|
|
letters, digits, hyphens, underscores, colons, or full stops, together known
|
|
as name characters.] Names beginning with the string "<code>xml</code>",
|
|
or <span>with</span> any string which would match <code>(('X'|'x') ('M'|'m') ('L'|'l'))</code>,
|
|
are reserved for standardization in this or future versions of this specification.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>The
|
|
Namespaces in XML Recommendation <a href="#xml-names">[XML Names]</a> assigns a meaning
|
|
to names containing colon characters. Therefore, authors should not use the
|
|
colon in XML names except for namespace purposes, but XML processors must
|
|
accept the colon as a name character.</p></div><p>An <a href="#NT-Nmtoken">Nmtoken</a> (name token) is any mixture of name
|
|
characters.</p><p>The first character of a Name <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be a NameStartChar, and any
|
|
other characters <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be NameChars; this mechanism is used to
|
|
prevent names from beginning with European (ASCII) digits or with
|
|
basic combining characters. Almost all characters are permitted in
|
|
names, except those which either are or reasonably could be used as
|
|
delimiters. The intention is to be inclusive rather than exclusive,
|
|
so that writing systems not yet encoded in Unicode can be used in
|
|
XML names. See <a href="#sec-suggested-names"><b>I Suggestions for XML Names</b></a> for suggestions on the creation of
|
|
names.</p><p>Document authors are encouraged to use names which are
|
|
meaningful words or combinations of words in natural languages, and
|
|
to avoid symbolic or white space characters in names. Note that
|
|
COLON, HYPHEN-MINUS, FULL STOP (period), LOW LINE (underscore), and
|
|
MIDDLE DOT are explicitly permitted.</p><p>The ASCII symbols and punctuation marks, along with a fairly
|
|
large group of Unicode symbol characters, are excluded from names
|
|
because they are more useful as delimiters in contexts where XML
|
|
names are used outside XML documents; providing this group gives
|
|
those contexts hard guarantees about what <em>cannot</em> be part of
|
|
an XML name. The character #x037E, GREEK QUESTION MARK, is excluded
|
|
because when normalized it becomes a semicolon, which could change
|
|
the meaning of entity references.</p> <h5><a name="IDABN1S" id="IDABN1S" />Names and Tokens</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-NameStartChar" id="NT-NameStartChar" />[4] </td><td><code>NameStartChar</code></td><td> ::= </td><td><code>":" | [A-Z] | "_" | [a-z] | [#xC0-#xD6] | [#xD8-#xF6] | [#xF8-#x2FF] | [#x370-#x37D] | [#x37F-#x1FFF] | [#x200C-#x200D] | [#x2070-#x218F] | [#x2C00-#x2FEF] | [#x3001-#xD7FF] | [#xF900-#xFDCF] | [#xFDF0-#xFFFD] | [#x10000-#xEFFFF]</code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-NameChar" id="NT-NameChar" />[4a] </td><td><code>NameChar</code></td><td> ::= </td><td><code><a href="#NT-NameStartChar">NameStartChar</a> | "-" | "." | [0-9] | #xB7 | [#x0300-#x036F] | [#x203F-#x2040]</code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-Name" id="NT-Name" />[5] </td><td><code>Name</code></td><td> ::= </td><td><code><a href="#NT-NameStartChar">NameStartChar</a> (<a href="#NT-NameChar">NameChar</a>)*</code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-Names" id="NT-Names" />[6] </td><td><code>Names</code></td><td> ::= </td><td><code><a href="#NT-Name">Name</a> (#x20 <a href="#NT-Name">Name</a>)*</code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-Nmtoken" id="NT-Nmtoken" />[7] </td><td><code>Nmtoken</code></td><td> ::= </td><td><code>(<a href="#NT-NameChar">NameChar</a>)+</code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-Nmtokens" id="NT-Nmtokens" />[8] </td><td><code>Nmtokens</code></td><td> ::= </td><td><code><a href="#NT-Nmtoken">Nmtoken</a> (#x20 <a href="#NT-Nmtoken">Nmtoken</a>)*</code></td></tr></tbody></table><div class="note"><p class="prefix"><b>Note:</b></p><p>The <a href="#NT-Names">Names</a>
|
|
and <a href="#NT-Nmtokens">Nmtokens</a> productions are used to define the validity
|
|
of tokenized attribute values after normalization (see <a href="#sec-attribute-types"><b>3.3.1 Attribute Types</b></a>).</p></div><p>Literal data is any quoted string not containing the quotation mark used
|
|
as a delimiter for that string. Literals are used for specifying the content
|
|
of internal entities (<a href="#NT-EntityValue">EntityValue</a>), the values
|
|
of attributes (<a href="#NT-AttValue">AttValue</a>), and external identifiers
|
|
(<a href="#NT-SystemLiteral">SystemLiteral</a>). Note that a <a href="#NT-SystemLiteral">SystemLiteral</a>
|
|
can be parsed without scanning for markup.</p> <h5><a name="IDAFR1S" id="IDAFR1S" />Literals</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-EntityValue" id="NT-EntityValue" />[9] </td><td><code>EntityValue</code></td><td> ::= </td><td><code>'"' ([^%&"] | <a href="#NT-PEReference">PEReference</a>
|
|
| <a href="#NT-Reference">Reference</a>)* '"' </code></td></tr><tr valign="baseline"><td /><td /><td /><td><code>| "'" ([^%&'] | <a href="#NT-PEReference">PEReference</a> | <a href="#NT-Reference">Reference</a>)* "'"</code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-AttValue" id="NT-AttValue" />[10] </td><td><code>AttValue</code></td><td> ::= </td><td><code>'"' ([^<&"] | <a href="#NT-Reference">Reference</a>)*
|
|
'"' </code></td></tr><tr valign="baseline"><td /><td /><td /><td><code>| "'" ([^<&'] | <a href="#NT-Reference">Reference</a>)*
|
|
"'"</code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-SystemLiteral" id="NT-SystemLiteral" />[11] </td><td><code>SystemLiteral</code></td><td> ::= </td><td><code>('"' [^"]* '"') | ("'" [^']* "'") </code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-PubidLiteral" id="NT-PubidLiteral" />[12] </td><td><code>PubidLiteral</code></td><td> ::= </td><td><code>'"' <a href="#NT-PubidChar">PubidChar</a>* '"'
|
|
| "'" (<a href="#NT-PubidChar">PubidChar</a> - "'")* "'"</code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-PubidChar" id="NT-PubidChar" />[13] </td><td><code>PubidChar</code></td><td> ::= </td><td><code>#x20 | #xD | #xA | [a-zA-Z0-9] | [-'()+,./:=?;!*#@$_%]</code></td></tr></tbody></table><div class="note"><p class="prefix"><b>Note:</b></p><p>Although
|
|
the <a href="#NT-EntityValue">EntityValue</a> production allows the definition
|
|
of a general entity consisting of a single explicit <code><</code> in the literal
|
|
(e.g., <code><!ENTITY mylt "<"></code>), it is strongly advised to avoid
|
|
this practice since any reference to that entity will cause a well-formedness
|
|
error.</p></div></div><div class="div2"> <h3><a name="syntax" id="syntax" />2.4 Character Data and Markup</h3><p><a title="Text" href="#dt-text">Text</a> consists of intermingled <a title="Character Data" href="#dt-chardata">character data</a> and markup. [<a name="dt-markup" id="dt-markup" title="Markup">Definition</a>: <b>Markup</b> takes the form of <a title="Start-Tag" href="#dt-stag">start-tags</a>, <a title="End Tag" href="#dt-etag">end-tags</a>, <a title="Empty" href="#dt-empty">empty-element tags</a>, <a title="Entity Reference" href="#dt-entref">entity references</a>, <a title="Character Reference" href="#dt-charref">character
|
|
references</a>, <a title="Comment" href="#dt-comment">comments</a>, <a title="CDATA Section" href="#dt-cdsection">CDATA section</a> delimiters, <a title="Document Type Declaration" href="#dt-doctype">document
|
|
type declarations</a>, <a title="Processing instruction" href="#dt-pi">processing instructions</a>, <a href="#NT-XMLDecl">XML declarations</a>, <a href="#NT-TextDecl">text declarations</a>,
|
|
and any white space that is at the top level of the document entity (that
|
|
is, outside the document element and not inside any other markup).]</p><p>[<a name="dt-chardata" id="dt-chardata" title="Character Data">Definition</a>: All text that is not markup
|
|
constitutes the <b>character data</b> of the document.]</p><p>The ampersand character (&) and the left angle bracket (<) <span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em></span> appear
|
|
in their literal form<span class="mustard">, except</span> when used as markup delimiters, or
|
|
within a <a title="Comment" href="#dt-comment">comment</a>, a <a title="Processing instruction" href="#dt-pi">processing
|
|
instruction</a>, or a <a title="CDATA Section" href="#dt-cdsection">CDATA section</a>.
|
|
|
|
If they are needed elsewhere, they <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be <a title="escape" href="#dt-escape">escaped</a>
|
|
using either <a title="Character Reference" href="#dt-charref">numeric character references</a>
|
|
or the strings "<code>&amp;</code>" and "<code>&lt;</code>"
|
|
respectively. The right angle bracket (>) <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> be represented using the string "<code>&gt;</code>",
|
|
and <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em>, <a title="For Compatibility" href="#dt-compat">for compatibility</a>, be escaped
|
|
using <span>either</span> "<code>&gt;</code>" or a character reference when it
|
|
appears in the string "<code>]]></code>" in content, when
|
|
that string is not marking the end of a <a title="CDATA Section" href="#dt-cdsection">CDATA
|
|
section</a>.</p><p>In the content of elements, character data is any string of characters
|
|
which does not contain the start-delimiter of any markup or the
|
|
CDATA-section-close delimiter,
|
|
"<code>]]></code>".
|
|
In a CDATA section,
|
|
character data is any string of characters not including the CDATA-section-close
|
|
delimiter.</p><p>To allow attribute values to contain both single and double quotes, the
|
|
apostrophe or single-quote character (') <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> be represented as "<code>&apos;</code>",
|
|
and the double-quote character (") as "<code>&quot;</code>".</p> <h5><a name="IDASZ1S" id="IDASZ1S" />Character Data</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-CharData" id="NT-CharData" />[14] </td><td><code>CharData</code></td><td> ::= </td><td><code>[^<&]* - ([^<&]* ']]>' [^<&]*)</code></td></tr></tbody></table></div><div class="div2"> <h3><a name="sec-comments" id="sec-comments" />2.5 Comments</h3><p>[<a name="dt-comment" id="dt-comment" title="Comment">Definition</a>: <b>Comments</b> <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> appear
|
|
anywhere in a document outside other <a title="Markup" href="#dt-markup">markup</a>;
|
|
in addition, they <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> appear within the document type declaration at places
|
|
allowed by the grammar. They are not part of the document's <a title="Character Data" href="#dt-chardata">character
|
|
data</a>; an XML processor <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em>, but need not, make it possible for an
|
|
application to retrieve the text of comments. <a title="For Compatibility" href="#dt-compat">For
|
|
compatibility</a>, the string "<code>--</code>" (double-hyphen)
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em> occur within comments.] Parameter
|
|
entity references <span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em> be</span> recognized within comments.</p> <h5><a name="IDAL11S" id="IDAL11S" />Comments</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-Comment" id="NT-Comment" />[15] </td><td><code>Comment</code></td><td> ::= </td><td><code>'<!--' ((<a href="#NT-Char">Char</a> - '-') | ('-'
|
|
(<a href="#NT-Char">Char</a> - '-')))* '-->'</code></td></tr></tbody></table><p>An example of a comment:</p><div class="exampleInner"><pre><!-- declarations for <head> & <body> --></pre></div><p>Note
|
|
that the grammar does not allow a comment ending in <code>---></code>. The
|
|
following example is <em>not</em> well-formed.</p><div class="exampleInner"><pre><!-- B+, B, or B---></pre></div></div><div class="div2"> <h3><a name="sec-pi" id="sec-pi" />2.6 Processing Instructions</h3><p>[<a name="dt-pi" id="dt-pi" title="Processing instruction">Definition</a>: <b>Processing instructions</b>
|
|
(PIs) allow documents to contain instructions for applications.]</p> <h5><a name="IDAD31S" id="IDAD31S" />Processing Instructions</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-PI" id="NT-PI" />[16] </td><td><code>PI</code></td><td> ::= </td><td><code>'<?' <a href="#NT-PITarget">PITarget</a> (<a href="#NT-S">S</a>
|
|
(<a href="#NT-Char">Char</a>* - (<a href="#NT-Char">Char</a>* '?>' <a href="#NT-Char">Char</a>*)))? '?>'</code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-PITarget" id="NT-PITarget" />[17] </td><td><code>PITarget</code></td><td> ::= </td><td><code><a href="#NT-Name">Name</a> - (('X' | 'x') ('M' |
|
|
'm') ('L' | 'l'))</code></td></tr></tbody></table><p>PIs are not part of the document's <a title="Character Data" href="#dt-chardata">character
|
|
data</a>, but <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be passed through to the application. The PI begins
|
|
with a target (<a href="#NT-PITarget">PITarget</a>) used to identify the application
|
|
to which the instruction is directed. The target names "<code>XML</code>", "<code>xml</code>",
|
|
and so on are reserved for standardization in this or future versions of this
|
|
specification. The XML <a title="Notation" href="#dt-notation">Notation</a> mechanism
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> be used for formal declaration of PI targets. Parameter
|
|
entity references <span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em> be</span> recognized within processing instructions.</p></div><div class="div2"> <h3><a name="sec-cdata-sect" id="sec-cdata-sect" />2.7 CDATA Sections</h3><p>[<a name="dt-cdsection" id="dt-cdsection" title="CDATA Section">Definition</a>: <b>CDATA sections</b> <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> occur anywhere character data may occur; they are used to escape blocks
|
|
of text containing characters which would otherwise be recognized as markup.
|
|
CDATA sections begin with the string "<code><![CDATA[</code>"
|
|
and end with the string "<code>]]></code>":]</p> <h5><a name="IDAOA2S" id="IDAOA2S" />CDATA Sections</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-CDSect" id="NT-CDSect" />[18] </td><td><code>CDSect</code></td><td> ::= </td><td><code><a href="#NT-CDStart">CDStart</a> <a href="#NT-CData">CData</a> <a href="#NT-CDEnd">CDEnd</a></code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-CDStart" id="NT-CDStart" />[19] </td><td><code>CDStart</code></td><td> ::= </td><td><code>'<![CDATA['</code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-CData" id="NT-CData" />[20] </td><td><code>CData</code></td><td> ::= </td><td><code>(<a href="#NT-Char">Char</a>* - (<a href="#NT-Char">Char</a>*
|
|
']]>' <a href="#NT-Char">Char</a>*)) </code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-CDEnd" id="NT-CDEnd" />[21] </td><td><code>CDEnd</code></td><td> ::= </td><td><code>']]>'</code></td></tr></tbody></table><p>Within a CDATA section, only the <a href="#NT-CDEnd">CDEnd</a> string is
|
|
recognized as markup, so that left angle brackets and ampersands may occur
|
|
in their literal form; they need not (and cannot) be escaped using "<code>&lt;</code>"
|
|
and "<code>&amp;</code>". CDATA sections cannot nest.</p><p>An example of a CDATA section, in which "<code><greeting></code>"
|
|
and "<code></greeting></code>" are recognized as <a title="Character Data" href="#dt-chardata">character data</a>, not <a title="Markup" href="#dt-markup">markup</a>:</p><div class="exampleInner"><pre><![CDATA[<greeting>Hello, world!</greeting>]]> </pre></div></div><div class="div2"> <h3><a name="sec-prolog-dtd" id="sec-prolog-dtd" />2.8 Prolog and Document Type Declaration</h3><p>[<a name="dt-xmldecl" id="dt-xmldecl" title="XML Declaration">Definition</a>: XML 1.1 documents <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em>
|
|
begin with an <b>XML declaration</b> which specifies the version of
|
|
XML being used.] For example, the following is a complete XML 1.1 document, <a title="Well-Formed" href="#dt-wellformed">well-formed</a> but not <a title="Validity" href="#dt-valid">valid</a>:</p><div class="exampleInner"><pre><?xml version="1.1"?>
|
|
<greeting>Hello, world!</greeting> </pre></div><p>but the following is an XML 1.0 document because it
|
|
does not have an XML declaration:</p><div class="exampleInner"><pre><greeting>Hello, world!</greeting></pre></div><p>The function of the markup in an XML document is to describe its storage and
|
|
logical structure and to associate <span>attribute
|
|
name-value</span> pairs with its logical structures. XML provides a mechanism, the
|
|
<a title="Document Type Declaration" href="#dt-doctype">document
|
|
type declaration</a>, to define constraints on the logical structure
|
|
and to support the use of predefined storage units. [<a name="dt-valid" id="dt-valid" title="Validity">Definition</a>: An XML document is <b>valid</b> if it has an associated
|
|
document type declaration and if the document complies with the constraints
|
|
expressed in it.]</p><p>The document type declaration <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> appear before the first <a title="Element" href="#dt-element">element</a>
|
|
in the document.</p> <h5><a name="xmldoc" id="xmldoc" />Prolog</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-prolog" id="NT-prolog" />[22] </td><td><code>prolog</code></td><td> ::= </td><td><code><a href="#NT-XMLDecl">XMLDecl</a> <a href="#NT-Misc">Misc</a>*
|
|
(<a href="#NT-doctypedecl">doctypedecl</a> <a href="#NT-Misc">Misc</a>*)?</code></td></tr><tr valign="baseline"><td><a name="NT-XMLDecl" id="NT-XMLDecl" />[23] </td><td><code>XMLDecl</code></td><td> ::= </td><td><code>'<?xml' <a href="#NT-VersionInfo">VersionInfo</a> <a href="#NT-EncodingDecl">EncodingDecl</a>? <a href="#NT-SDDecl">SDDecl</a>? <a href="#NT-S">S</a>?'?>'</code></td></tr><tr valign="baseline"><td><a name="NT-VersionInfo" id="NT-VersionInfo" />[24] </td><td><code>VersionInfo</code></td><td> ::= </td><td><code><a href="#NT-S">S</a> 'version' <a href="#NT-Eq">Eq</a>
|
|
("'" <a href="#NT-VersionNum">VersionNum</a> "'" | '"' <a href="#NT-VersionNum">VersionNum</a>
|
|
'"')</code></td></tr><tr valign="baseline"><td><a name="NT-Eq" id="NT-Eq" />[25] </td><td><code>Eq</code></td><td> ::= </td><td><code><a href="#NT-S">S</a>? '=' <a href="#NT-S">S</a>?</code></td></tr><tr valign="baseline"><td><a name="NT-VersionNum" id="NT-VersionNum" />[26] </td><td><code>VersionNum</code></td><td> ::= </td><td><code>'1.1'</code></td></tr><tr valign="baseline"><td><a name="NT-Misc" id="NT-Misc" />[27] </td><td><code>Misc</code></td><td> ::= </td><td><code><a href="#NT-Comment">Comment</a> | <a href="#NT-PI">PI</a>
|
|
| <a href="#NT-S">S</a></code></td></tr></tbody></table><p>[<a name="dt-doctype" id="dt-doctype" title="Document Type Declaration">Definition</a>: The XML <b>document
|
|
type declaration</b> contains or points to <a title="markup declaration" href="#dt-markupdecl">markup
|
|
declarations</a> that provide a grammar for a class of documents. This
|
|
grammar is known as a document type definition, or <b>DTD</b>. The document
|
|
type declaration can point to an external subset (a special kind of <a title="External Entity" href="#dt-extent">external entity</a>) containing markup declarations,
|
|
or can contain the markup declarations directly in an internal subset, or
|
|
can do both. The DTD for a document consists of both subsets taken together.]</p><p>[<a name="dt-markupdecl" id="dt-markupdecl" title="markup declaration">Definition</a>: A <b>markup declaration</b>
|
|
is an <a title="Element Type declaration" href="#dt-eldecl">element type declaration</a>, an <a title="Attribute-List Declaration" href="#dt-attdecl">attribute-list declaration</a>, an <a title="entity declaration" href="#dt-entdecl">entity
|
|
declaration</a>, or a <a title="Notation Declaration" href="#dt-notdecl">notation declaration</a>.]
|
|
These declarations <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> be contained in whole or in part within <a title="Parameter entity" href="#dt-PE">parameter
|
|
entities</a>, as described in the well-formedness and validity constraints
|
|
below. For further
|
|
information, see <a href="#sec-physical-struct"><b>4 Physical Structures</b></a>.</p> <h5><a name="dtd" id="dtd" />Document Type Definition</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-doctypedecl" id="NT-doctypedecl" />[28] </td><td><code>doctypedecl</code></td><td> ::= </td><td><code>'<!DOCTYPE' <a href="#NT-S">S</a> <a href="#NT-Name">Name</a>
|
|
(<a href="#NT-S">S</a> <a href="#NT-ExternalID">ExternalID</a>)? <a href="#NT-S">S</a>?
|
|
('[' <a href="#NT-intSubset">intSubset</a> ']' <a href="#NT-S">S</a>?)? '>'</code></td><td><a href="#vc-roottype">[VC: Root Element Type]</a></td></tr><tr valign="baseline"><td /><td /><td /><td /><td><a href="#ExtSubset">[WFC: External Subset]</a></td></tr><tr valign="baseline"><td><a name="NT-DeclSep" id="NT-DeclSep" />[28a] </td><td><code>DeclSep</code></td><td> ::= </td><td><code><a href="#NT-PEReference">PEReference</a> | <a href="#NT-S">S</a></code></td><td><a href="#PE-between-Decls">[WFC: PE Between Declarations]</a></td></tr><tr valign="baseline"><td><a name="NT-intSubset" id="NT-intSubset" />[28b] </td><td><code>intSubset</code></td><td> ::= </td><td><code>(<a href="#NT-markupdecl">markupdecl</a> | <a href="#NT-DeclSep">DeclSep</a>)*</code></td></tr><tr valign="baseline"><td><a name="NT-markupdecl" id="NT-markupdecl" />[29] </td><td><code>markupdecl</code></td><td> ::= </td><td><code><a href="#NT-elementdecl">elementdecl</a> | <a href="#NT-AttlistDecl">AttlistDecl</a> | <a href="#NT-EntityDecl">EntityDecl</a>
|
|
| <a href="#NT-NotationDecl">NotationDecl</a> | <a href="#NT-PI">PI</a> | <a href="#NT-Comment">Comment</a></code></td><td><a href="#vc-PEinMarkupDecl">[VC: Proper Declaration/PE Nesting]</a></td></tr><tr valign="baseline"><td /><td /><td /><td /><td><a href="#wfc-PEinInternalSubset">[WFC: PEs in Internal Subset]</a></td></tr></tbody></table><p>Note
|
|
that it is possible to construct a well-formed document containing a <a href="#NT-doctypedecl">doctypedecl</a>
|
|
that neither points to an external subset nor contains an internal subset.</p><p>The markup declarations <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> be made up in whole or in part of the <a title="Replacement Text" href="#dt-repltext">replacement text</a> of <a title="Parameter entity" href="#dt-PE">parameter
|
|
entities</a>. The productions later in this specification for individual
|
|
nonterminals (<a href="#NT-elementdecl">elementdecl</a>, <a href="#NT-AttlistDecl">AttlistDecl</a>,
|
|
and so on) describe the declarations <em>after</em> all the parameter
|
|
entities have been <a title="Include" href="#dt-include">included</a>.</p><p>Parameter
|
|
entity references are recognized anywhere in the DTD (internal and external
|
|
subsets and external parameter entities), except in literals, processing instructions,
|
|
comments, and the contents of ignored conditional sections (see <a href="#sec-condition-sect"><b>3.4 Conditional Sections</b></a>).
|
|
They are also recognized in entity value literals. The use of parameter entities
|
|
in the internal subset is restricted as described below.</p><div class="constraint"><p class="prefix"><a name="vc-roottype" id="vc-roottype" /><b>Validity constraint: Root Element Type</b></p><p>The <a href="#NT-Name">Name</a>
|
|
in the document type declaration <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> match the element type of the <a title="Root Element" href="#dt-root">root element</a>.</p></div><div class="constraint"><p class="prefix"><a name="vc-PEinMarkupDecl" id="vc-PEinMarkupDecl" /><b>Validity constraint: Proper Declaration/PE Nesting</b></p><p>Parameter-entity <a title="Replacement Text" href="#dt-repltext">replacement text</a> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be properly nested with markup declarations. That is to say, if either
|
|
the first character or the last character of a markup declaration (<a href="#NT-markupdecl">markupdecl</a>
|
|
above) is contained in the replacement text for a <a title="Parameter-entity reference" href="#dt-PERef">parameter-entity
|
|
reference</a>, both <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be contained in the same replacement text.</p></div><div class="constraint"><p class="prefix"><a name="wfc-PEinInternalSubset" id="wfc-PEinInternalSubset" /><b>Well-formedness constraint: PEs in Internal Subset</b></p><p>In
|
|
the internal DTD subset, <a title="Parameter-entity reference" href="#dt-PERef">parameter-entity references</a> <span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em> occur within markup declarations; they <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> occur where markup declarations can occur</span>.
|
|
(This does not apply to references that occur in external parameter entities
|
|
or to the external subset.)</p></div><div class="constraint"><p class="prefix"><a name="ExtSubset" id="ExtSubset" /><b>Well-formedness constraint: External Subset</b></p><p>The external subset, if any, <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> match the production for <a href="#NT-extSubset">extSubset</a>.</p></div><div class="constraint"><p class="prefix"><a name="PE-between-Decls" id="PE-between-Decls" /><b>Well-formedness constraint: PE Between Declarations</b></p><p>The replacement text of a parameter entity reference
|
|
in a <a href="#NT-DeclSep">DeclSep</a> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> match the production <a href="#NT-extSubsetDecl">extSubsetDecl</a>.</p></div><p>Like the internal subset, the external subset and any external parameter
|
|
entities referenced
|
|
in a <a href="#NT-DeclSep">DeclSep</a> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> consist of a series of
|
|
complete markup declarations of the types allowed by the non-terminal symbol <a href="#NT-markupdecl">markupdecl</a>, interspersed with white space or <a title="Parameter-entity reference" href="#dt-PERef">parameter-entity references</a>. However, portions of
|
|
the contents of the external subset or of these
|
|
external parameter entities <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> conditionally be ignored by using the <a title="conditional section" href="#dt-cond-section">conditional section</a> construct; this is not
|
|
allowed in the internal subset<span> but is
|
|
allowed in external parameter entities referenced in the internal subset</span>.</p> <h5><a name="ext-Subset" id="ext-Subset" />External Subset</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-extSubset" id="NT-extSubset" />[30] </td><td><code>extSubset</code></td><td> ::= </td><td><code><a href="#NT-TextDecl">TextDecl</a>? <a href="#NT-extSubsetDecl">extSubsetDecl</a></code></td></tr><tr valign="baseline"><td><a name="NT-extSubsetDecl" id="NT-extSubsetDecl" />[31] </td><td><code>extSubsetDecl</code></td><td> ::= </td><td><code>( <a href="#NT-markupdecl">markupdecl</a> | <a href="#NT-conditionalSect">conditionalSect</a> | <a href="#NT-DeclSep">DeclSep</a>)*</code></td></tr></tbody></table><p>The external subset and external parameter entities also differ from the
|
|
internal subset in that in them, <a title="Parameter-entity reference" href="#dt-PERef">parameter-entity
|
|
references</a> are permitted <em>within</em> markup declarations,
|
|
not only <em>between</em> markup declarations.</p><p>An example of an XML document with a document type declaration:</p><div class="exampleInner"><pre><?xml version="1.1"?>
|
|
<!DOCTYPE greeting SYSTEM "hello.dtd">
|
|
<greeting>Hello, world!</greeting> </pre></div><p>The <a title="System Identifier" href="#dt-sysid">system identifier</a> "<code>hello.dtd</code>"
|
|
gives the address (a URI reference) of a DTD for the document.</p><p>The declarations can also be given locally, as in this example:</p><div class="exampleInner"><pre><?xml version="1.1" encoding="UTF-8" ?>
|
|
<!DOCTYPE greeting [
|
|
<!ELEMENT greeting (#PCDATA)>
|
|
]>
|
|
<greeting>Hello, world!</greeting></pre></div><p>If both the external and internal subsets are used, the internal subset
|
|
<span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be</span> considered to occur before the external subset.
|
|
This has the effect that entity and attribute-list declarations in the internal
|
|
subset take precedence over those in the external subset.</p><p>XML 1.1 processors <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> accept XML 1.0
|
|
documents as well. If a document is well-formed or valid XML 1.0, and provided it
|
|
does not contain any control characters
|
|
in the range [#x7F-#x9F] other than as character escapes, it may be
|
|
made well-formed or valid XML 1.1 respectively simply by changing the
|
|
version number.</p></div><div class="div2"> <h3><a name="sec-rmd" id="sec-rmd" />2.9 Standalone Document Declaration</h3><p>Markup declarations can affect the content of the document, as passed from
|
|
an <a title="XML Processor" href="#dt-xml-proc">XML processor</a> to an application; examples
|
|
are attribute defaults and entity declarations. The standalone document declaration,
|
|
which <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> appear as a component of the XML declaration, signals whether or
|
|
not there are such declarations which appear external to the <a title="Document Entity" href="#dt-docent">document
|
|
entity</a>
|
|
or in parameter entities. [<a name="dt-extmkpdecl" id="dt-extmkpdecl" title="External Markup Declaration">Definition</a>: An <b>external
|
|
markup declaration</b> is defined as a markup declaration occurring in
|
|
the external subset or in a parameter entity (external or internal, the latter
|
|
being included because non-validating processors are not required to read
|
|
them).]</p> <h5><a name="fulldtd" id="fulldtd" />Standalone Document Declaration</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-SDDecl" id="NT-SDDecl" />[32] </td><td><code>SDDecl</code></td><td> ::= </td><td><code>#x20+ 'standalone' <a href="#NT-Eq">Eq</a>
|
|
(("'" ('yes' | 'no') "'") | ('"' ('yes' | 'no') '"')) </code></td><td><a href="#vc-check-rmd">[VC: Standalone Document Declaration]</a></td></tr></tbody></table><p>In a standalone document declaration, the value "yes" indicates
|
|
that there are no <a title="External Markup Declaration" href="#dt-extmkpdecl">external markup declarations</a> which
|
|
affect the information passed from the XML processor to the application. The
|
|
value "no" indicates that there are or may be such external
|
|
markup declarations. Note that the standalone document declaration only denotes
|
|
the presence of external <em>declarations</em>; the presence, in a document,
|
|
of references to external <em>entities</em>, when those entities are internally
|
|
declared, does not change its standalone status.</p><p>If there are no external markup declarations, the standalone document declaration
|
|
has no meaning. If there are external markup declarations but there is no
|
|
standalone document declaration, the value "no" is assumed.</p><p>Any XML document for which <code>standalone="no"</code> holds can be converted
|
|
algorithmically to a standalone document, which may be desirable for some
|
|
network delivery applications.</p><div class="constraint"><p class="prefix"><a name="vc-check-rmd" id="vc-check-rmd" /><b>Validity constraint: Standalone Document Declaration</b></p><p>The
|
|
standalone document declaration <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> have the value "no" if
|
|
any external markup declarations contain declarations of:</p><ul><li><p>attributes with <a title="Attribute Default" href="#dt-default">default</a> values,
|
|
if elements to which these attributes apply appear in the document without
|
|
specifications of values for these attributes, or</p></li><li><p>entities (other than <code>amp</code>,
|
|
<code>lt</code>,
|
|
<code>gt</code>,
|
|
<code>apos</code>,
|
|
<code>quot</code>), if <a title="Entity Reference" href="#dt-entref">references</a>
|
|
to those entities appear in the document, or</p></li><li><p>attributes with
|
|
tokenized types, where the
|
|
attribute appears in the document with a value such that
|
|
<a href="#AVNormalize"><cite>normalization</cite></a>
|
|
will produce a different value from that which would be produced
|
|
in the absence of the declaration, or</p></li><li><p>element types with <a title="Element content" href="#dt-elemcontent">element content</a>,
|
|
if white space occurs directly within any instance of those types.</p></li></ul></div><p>An example XML declaration with a standalone document declaration:</p><div class="exampleInner"><pre><?xml version="1.1" standalone='yes'?></pre></div></div><div class="div2"> <h3><a name="sec-white-space" id="sec-white-space" />2.10 White Space Handling</h3><p>In editing XML documents, it is often convenient to use "white space"
|
|
(spaces, tabs, and blank lines)
|
|
to set apart the markup for greater readability. Such white space is typically
|
|
not intended for inclusion in the delivered version of the document. On the
|
|
other hand, "significant" white space that should be preserved
|
|
in the delivered version is common, for example in poetry and source code.</p><p>An <a title="XML Processor" href="#dt-xml-proc">XML processor</a> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> always pass
|
|
all characters in a document that are not markup through to the application.
|
|
A <a title="Validating Processor" href="#dt-validating"> validating XML processor</a> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> also
|
|
inform the application which of these characters constitute white space appearing
|
|
in <a title="Element content" href="#dt-elemcontent">element content</a>.</p><p>A special <a title="Attribute" href="#dt-attr">attribute</a> named <code>xml:space</code> <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> be attached to an element to signal an intention that in that element,
|
|
white space should be preserved by applications. In valid documents, this
|
|
attribute, like any other, <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be <a title="Attribute-List Declaration" href="#dt-attdecl">declared</a>
|
|
if it is used. When declared, it <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be given as an <a title="Enumerated Attribute
Values" href="#dt-enumerated">enumerated
|
|
type</a> whose values
|
|
are one or both of "default" and "preserve".
|
|
For example:</p><div class="exampleInner"><pre><!ATTLIST poem xml:space (default|preserve) 'preserve'>
|
|
<!ATTLIST pre xml:space (preserve) #FIXED 'preserve'></pre></div><p>The value "default" signals that applications' default white-space
|
|
processing modes are acceptable for this element; the value "preserve"
|
|
indicates the intent that applications preserve all the white space. This
|
|
declared intent is considered to apply to all elements within the content
|
|
of the element where it is specified, unless <span>overridden</span> with
|
|
another instance of the <code>xml:space</code> attribute. <span>This specification does not give meaning to any value of <code>xml:space</code> other than "default" and "preserve". It is an error for other values to be specified; the XML processor <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> report the error or <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> recover by ignoring the attribute specification or by reporting the (erroneous) value to the application. Applications may ignore or reject erroneous values.</span></p><p>The <a title="Root Element" href="#dt-root">root element</a> of any document is considered
|
|
to have signaled no intentions as regards application space handling, unless
|
|
it provides a value for this attribute or the attribute is declared with a
|
|
default value.</p></div><div class="div2"> <h3><a name="sec-line-ends" id="sec-line-ends" />2.11 End-of-Line Handling</h3><p>XML <a title="Text Entity" href="#dt-parsedent">parsed entities</a> are often stored
|
|
in computer files which, for editing convenience, are organized into lines.
|
|
These lines are typically separated by some combination of the characters
|
|
CARRIAGE RETURN (#xD) and LINE FEED (#xA).</p><p>To
|
|
simplify the tasks of <a title="Application" href="#dt-app">applications</a>, the
|
|
<span><a title="XML Processor" href="#dt-xml-proc">XML
|
|
processor</a> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> behave as if it</span> normalized all line breaks in external parsed
|
|
entities (including the document entity) on input, before parsing, by translating
|
|
|
|
<span>all of the following to a single #xA character:</span></p><ol type="1"><li><p>the two-character sequence #xD #xA</p></li><li><p>the two-character sequence #xD #x85</p></li><li><p>the single character #x85</p></li><li><p>the single character #x2028</p></li><li><p>any #xD character that is not immediately followed by #xA or #x85.</p></li></ol><p> The characters #x85 and #x2028 cannot be reliably recognized and
|
|
translated until an entity's encoding declaration (if present) has
|
|
been read. Therefore, it is a fatal error to use them within the XML
|
|
declaration or text declaration.
|
|
</p></div><div class="div2"> <h3><a name="sec-lang-tag" id="sec-lang-tag" />2.12 Language Identification</h3><p>In document processing, it is often useful to identify the natural or formal
|
|
language in which the content is written. A special <a title="Attribute" href="#dt-attr">attribute</a>
|
|
named <code>xml:lang</code> <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> be inserted in documents to specify the language
|
|
used in the contents and attribute values of any element in an XML document.
|
|
In valid documents, this attribute, like any other, <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be <a title="Attribute-List Declaration" href="#dt-attdecl">declared</a>
|
|
if it is used. The
|
|
values of the attribute are language identifiers as defined by <a href="#RFC1766">[IETF RFC 3066]</a>, <cite>Tags
|
|
for the Identification of Languages</cite>, or its successor<span>; in addition, the empty string <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> be specified</span>.</p><p>(Productions 33 through 38 have been removed.)</p><p>For example:</p><div class="exampleInner"><pre><p xml:lang="en">The quick brown fox jumps over the lazy dog.</p>
|
|
<p xml:lang="en-GB">What colour is it?</p>
|
|
<p xml:lang="en-US">What color is it?</p>
|
|
<sp who="Faust" desc='leise' xml:lang="de">
|
|
<l>Habe nun, ach! Philosophie,</l>
|
|
<l>Juristerei, und Medizin</l>
|
|
<l>und leider auch Theologie</l>
|
|
<l>durchaus studiert mit hei&#xDF;em Bem&#xFC;h'n.</l>
|
|
</sp></pre></div><p>The intent declared with <code>xml:lang</code> is considered to apply to
|
|
all attributes and content of the element where it is specified, unless overridden
|
|
with an instance of <code>xml:lang</code> on another element within that content. <span>In particular, the empty value of <code>xml:lang</code> is used on an element B to override a specification of <code>xml:lang</code> on an enclosing element A, without specifying another language. Within B, it is considered that there is no language information available, just as if <code>xml:lang</code> had not been specified on B or any of its ancestors.</span></p><div class="note"><p class="prefix"><b>Note:</b></p><p>Language information may also be provided by external transport protocols (e.g. HTTP or
|
|
MIME). When available, this information may be used by XML applications, but the more local
|
|
information provided by <code>xml:lang</code> should be considered to override it.
|
|
</p></div><p>A simple declaration for <code>xml:lang</code> might take the form</p><div class="exampleInner"><pre>xml:lang <span>CDATA</span> #IMPLIED</pre></div><p>but specific default values <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> also be given, if appropriate. In a collection
|
|
of French poems for English students, with glosses and notes in English, the <code>xml:lang</code>
|
|
attribute might be declared this way:</p><div class="exampleInner"><pre><!ATTLIST poem xml:lang <span>CDATA</span> 'fr'>
|
|
<!ATTLIST gloss xml:lang <span>CDATA</span> 'en'>
|
|
<!ATTLIST note xml:lang <span>CDATA</span> 'en'></pre></div></div><div class="div2"> <h3><a name="sec-normalization-checking" id="sec-normalization-checking" />2.13 Normalization Checking</h3><p>All XML <a title="Text Entity" href="#dt-parsedent"> parsed
|
|
entities</a> (including <a title="Document Entity" href="#dt-docent"> document
|
|
entities</a>) <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> be <a title="fully normalized" href="#dt-fullnorm">fully
|
|
normalized</a> as per the definition of
|
|
<a href="#sec-CharNorm"><b>B Definitions for Character Normalization</b></a> supplemented by the following definitions of
|
|
<em><a name="dt-relconst" id="dt-relconst" />relevant constructs</em> for XML:</p><ol type="1"><li><p>The <a title="Replacement Text" href="#dt-repltext">
|
|
replacement text</a> of all <a title="Text Entity" href="#dt-parsedent">parsed
|
|
entities</a></p></li><li><p>All text matching, in context, one of the following
|
|
productions:</p><ol type="a"><li><p><a href="#NT-CData">
|
|
CData</a></p></li><li><p><a href="#NT-CharData">
|
|
CharData</a></p></li><li><p><a href="#NT-content">
|
|
content</a></p></li><li><p><a href="#NT-Name"> Name</a></p></li><li><p><a href="#NT-Nmtoken">
|
|
Nmtoken</a></p></li></ol></li></ol><p>However, a document is still well-formed even if it is not
|
|
<a title="fully normalized" href="#dt-fullnorm">fully normalized</a>.
|
|
XML processors <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> provide a user option to verify that the document being
|
|
processed is in <a title="fully normalized" href="#dt-fullnorm">fully normalized</a> form, and report to the application whether
|
|
it is or not. The option to not verify <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> be chosen only when the
|
|
input text is <a title="certified" href="#dt-certified">certified</a>,
|
|
as defined by <a href="#sec-CharNorm"><b>B Definitions for Character Normalization</b></a>.</p><p>The verification of full normalization <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be carried out as if by
|
|
first verifying that the entity is in <a title="include-normalized" href="#dt-inclnorm">include-normalized</a>
|
|
form as defined by <a href="#sec-CharNorm"><b>B Definitions for Character Normalization</b></a> and by then verifying that none of the relevant
|
|
constructs listed above begins (after character references are
|
|
expanded) with a <a title="composing character" href="#dt-compchar">composing character</a> as defined by
|
|
<a href="#sec-CharNorm"><b>B Definitions for Character Normalization</b></a>.
|
|
Non-validating processors <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> ignore possible
|
|
denormalizations that would be caused by inclusion of external
|
|
entities that they do not read.</p><div class="note"><p class="prefix"><b>Note:</b></p><p>The <a title="composing character" href="#dt-compchar">composing character</a> are all
|
|
Unicode characters of non-zero combining class, plus a small number
|
|
of class-zero characters that nevertheless take part as a
|
|
non-initial character in certain Unicode canonical
|
|
decompositions. Since these characters are meant to follow
|
|
base characters, restricting relevant constructs (including
|
|
content) from beginning with a <a title="composing character" href="#dt-compchar">composing character</a> does not
|
|
meaningfully diminish the expressiveness of XML.</p></div><p>If, while verifying full normalization, a processor encounters
|
|
characters for which it cannot determine the normalization
|
|
properties (i.e., characters introduced in a version of Unicode <a href="#Unicode">[Unicode]</a>
|
|
later than the one used in the implementation of the processor),
|
|
then the processor <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em>, at user option, ignore any possible
|
|
denormalizations caused by these characters. The option to ignore
|
|
those denormalizations <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD NOT</em> be chosen by applications when
|
|
reliability or security are critical.</p><p> XML processors <em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em> transform the input to be in
|
|
<a title="fully normalized" href="#dt-fullnorm">fully normalized</a> form.
|
|
XML applications that create XML 1.1 output
|
|
from either XML 1.1 or XML 1.0 input <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> ensure that the output
|
|
is <a title="fully normalized" href="#dt-fullnorm">fully normalized</a>; it is not necessary for internal processing
|
|
forms to be <a title="fully normalized" href="#dt-fullnorm">fully normalized</a>.</p><p>The purpose of this section is to strongly encourage XML
|
|
processors to ensure that the creators of XML documents have
|
|
properly normalized them, so that XML applications can make tests
|
|
such as identity comparisons of strings without having to worry
|
|
about the different possible "spellings" of strings which
|
|
Unicode allows.
|
|
</p><p>When entities are in a non-Unicode encoding, if the processor
|
|
transcodes them to Unicode, it <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> use a normalizing transcoder.
|
|
</p></div></div><div class="div1"> <h2><a name="sec-logical-struct" id="sec-logical-struct" />3 Logical Structures</h2><p>[<a name="dt-element" id="dt-element" title="Element">Definition</a>: Each <a title="XML Document" href="#dt-xml-doc">XML
|
|
document</a> contains one or more <b>elements</b>, the boundaries
|
|
of which are either delimited by <a title="Start-Tag" href="#dt-stag">start-tags</a>
|
|
and <a title="End Tag" href="#dt-etag">end-tags</a>, or, for <a title="Empty" href="#dt-empty">empty</a>
|
|
elements, by an <a title="empty-element tag" href="#dt-eetag">empty-element tag</a>. Each
|
|
element has a type, identified by name, sometimes called its "generic
|
|
identifier" (GI), and <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> have a set of attribute specifications.]
|
|
Each attribute specification has a <a title="Attribute Name" href="#dt-attrname">name</a>
|
|
and a <a title="Attribute Value" href="#dt-attrval">value</a>.</p> <h5><a name="IDATJ3S" id="IDATJ3S" />Element</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-element" id="NT-element" />[39] </td><td><code>element</code></td><td> ::= </td><td><code><a href="#NT-EmptyElemTag">EmptyElemTag</a></code></td></tr><tr valign="baseline"><td /><td /><td /><td><code>| <a href="#NT-STag">STag</a> <a href="#NT-content">content</a> <a href="#NT-ETag">ETag</a></code></td><td><a href="#GIMatch">[WFC: Element Type Match]</a></td></tr><tr valign="baseline"><td /><td /><td /><td /><td><a href="#elementvalid">[VC: Element Valid]</a></td></tr></tbody></table><p>This specification does not constrain the semantics, use, or (beyond syntax)
|
|
names of the element types and attributes, except that names beginning with
|
|
a match to <code>(('X'|'x')('M'|'m')('L'|'l'))</code> are reserved for standardization
|
|
in this or future versions of this specification.</p><div class="constraint"><p class="prefix"><a name="GIMatch" id="GIMatch" /><b>Well-formedness constraint: Element Type Match</b></p><p>The <a href="#NT-Name">Name</a>
|
|
in an element's end-tag <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> match the element type in the start-tag.</p></div><div class="constraint"><p class="prefix"><a name="elementvalid" id="elementvalid" /><b>Validity constraint: Element Valid</b></p><p>An element is valid
|
|
if there is a declaration matching <a href="#NT-elementdecl">elementdecl</a>
|
|
where the <a href="#NT-Name">Name</a> matches the element type, and one of
|
|
the following holds:</p><ol type="1"><li><p>The declaration matches <b>EMPTY</b> and the element has no <a title="Content" href="#dt-content">content</a> <span>(not even entity
|
|
references, comments, PIs or white space)</span>.</p></li><li><p>The declaration matches <a href="#NT-children">children</a> and the
|
|
sequence of <a title="Parent/Child" href="#dt-parentchild">child elements</a> belongs
|
|
to the language generated by the regular expression in the content model,
|
|
with optional white space<span>, comments and
|
|
PIs (i.e. markup matching production [27] <a href="#NT-Misc">Misc</a>)</span> between the
|
|
start-tag and the first child element, between child elements, or between
|
|
the last child element and the end-tag. Note that a CDATA section containing
|
|
only white space <span>or a reference
|
|
to an entity whose replacement text is character references expanding to white
|
|
space</span> <span>do</span> not
|
|
match the nonterminal <a href="#NT-S">S</a>, and
|
|
hence cannot appear in these positions<span>; however, a
|
|
reference to an internal entity with a literal value consisting of character
|
|
references expanding to white space does match <a href="#NT-S">S</a>, since its
|
|
replacement text is the white space resulting from expansion of the character
|
|
references</span>.</p></li><li><p>The declaration matches <a href="#NT-Mixed">Mixed</a> and the content
|
|
<span>(after replacing
|
|
any entity references with their replacement text)</span> consists of
|
|
<a title="Character Data" href="#dt-chardata">character data</a><span>,
|
|
<a title="Comment" href="#dt-comment">comments</a>, <a title="Processing instruction" href="#dt-pi">PIs</a></span> and <a title="Parent/Child" href="#dt-parentchild">child elements</a> whose types match names in the
|
|
content model.</p></li><li><p>The declaration matches <b>ANY</b>, and the
|
|
<span>content
|
|
<span>(after replacing
|
|
any entity references with their replacement text)</span>
|
|
consists of character data and <a title="Parent/Child" href="#dt-parentchild">child elements</a>
|
|
whose types</span>
|
|
have been declared.</p></li></ol></div><div class="div2"> <h3><a name="sec-starttags" id="sec-starttags" />3.1 Start-Tags, End-Tags, and Empty-Element Tags</h3><p>[<a name="dt-stag" id="dt-stag" title="Start-Tag">Definition</a>: The beginning of every non-empty
|
|
XML element is marked by a <b>start-tag</b>.]</p> <h5><a name="IDA3O3S" id="IDA3O3S" />Start-tag</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-STag" id="NT-STag" />[40] </td><td><code>STag</code></td><td> ::= </td><td><code>'<' <a href="#NT-Name">Name</a> (<a href="#NT-S">S</a> <a href="#NT-Attribute">Attribute</a>)* <a href="#NT-S">S</a>? '>'</code></td><td><a href="#uniqattspec">[WFC: Unique Att Spec]</a></td></tr><tr valign="baseline"><td><a name="NT-Attribute" id="NT-Attribute" />[41] </td><td><code>Attribute</code></td><td> ::= </td><td><code><a href="#NT-Name">Name</a> <a href="#NT-Eq">Eq</a> <a href="#NT-AttValue">AttValue</a></code></td><td><a href="#ValueType">[VC: Attribute Value Type]</a></td></tr><tr valign="baseline"><td /><td /><td /><td /><td><a href="#NoExternalRefs">[WFC: No External Entity References]</a></td></tr><tr valign="baseline"><td /><td /><td /><td /><td><a href="#CleanAttrVals">[WFC: No < in Attribute Values]</a></td></tr></tbody></table><p>The <a href="#NT-Name">Name</a> in the start- and end-tags gives the element's <b>type</b>. [<a name="dt-attr" id="dt-attr" title="Attribute">Definition</a>: The <a href="#NT-Name">Name</a>-<a href="#NT-AttValue">AttValue</a>
|
|
pairs are referred to as the <b>attribute specifications</b> of the
|
|
element], [<a name="dt-attrname" id="dt-attrname" title="Attribute Name">Definition</a>: with the <a href="#NT-Name">Name</a> in each pair referred to as the <b>attribute name</b>]
|
|
and [<a name="dt-attrval" id="dt-attrval" title="Attribute Value">Definition</a>: the content of the <a href="#NT-AttValue">AttValue</a> (the text between the <code>'</code> or <code>"</code>
|
|
delimiters) as the <b>attribute value</b>.] Note
|
|
that the order of attribute specifications in a start-tag or empty-element
|
|
tag is not significant.</p><div class="constraint"><p class="prefix"><a name="uniqattspec" id="uniqattspec" /><b>Well-formedness constraint: Unique Att Spec</b></p><p><span class="mustard">An attribute name
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em></span> appear more than once in the same start-tag or empty-element tag.</p></div><div class="constraint"><p class="prefix"><a name="ValueType" id="ValueType" /><b>Validity constraint: Attribute Value Type</b></p><p>The attribute <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em>
|
|
have been declared; the value <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be of the type declared for it. (For attribute
|
|
types, see <a href="#attdecls"><b>3.3 Attribute-List Declarations</b></a>.)</p></div><div class="constraint"><p class="prefix"><a name="NoExternalRefs" id="NoExternalRefs" /><b>Well-formedness constraint: No External Entity References</b></p><p>Attribute
|
|
values <span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em></span> contain direct or indirect entity references to external entities.</p></div><div class="constraint"><p class="prefix"><a name="CleanAttrVals" id="CleanAttrVals" /><b>Well-formedness constraint: No <code><</code> in Attribute Values</b></p><p>The <a title="Replacement Text" href="#dt-repltext">replacement text</a> of any entity
|
|
referred to directly or indirectly in an attribute value <em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em> contain a <code><</code>.</p></div><p>An example of a start-tag:</p><div class="exampleInner"><pre><termdef id="dt-dog" term="dog"></pre></div><p>[<a name="dt-etag" id="dt-etag" title="End Tag">Definition</a>: The end of every element that begins
|
|
with a start-tag <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be marked by an <b>end-tag</b> containing a name
|
|
that echoes the element's type as given in the start-tag:]</p> <h5><a name="IDA3U3S" id="IDA3U3S" />End-tag</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-ETag" id="NT-ETag" />[42] </td><td><code>ETag</code></td><td> ::= </td><td><code>'</' <a href="#NT-Name">Name</a> <a href="#NT-S">S</a>?
|
|
'>'</code></td></tr></tbody></table><p>An example of an end-tag:</p><div class="exampleInner"><pre></termdef></pre></div><p>[<a name="dt-content" id="dt-content" title="Content">Definition</a>: The <a title="Text" href="#dt-text">text</a>
|
|
between the start-tag and end-tag is called the element's <b>content</b>:]</p> <h5><a name="IDAKW3S" id="IDAKW3S" />Content of Elements</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-content" id="NT-content" />[43] </td><td><code>content</code></td><td> ::= </td><td><code><a href="#NT-CharData">CharData</a>? ((<a href="#NT-element">element</a>
|
|
| <a href="#NT-Reference">Reference</a> | <a href="#NT-CDSect">CDSect</a>
|
|
| <a href="#NT-PI">PI</a> | <a href="#NT-Comment">Comment</a>) <a href="#NT-CharData">CharData</a>?)*</code></td></tr></tbody></table><p>[<a name="dt-empty" id="dt-empty" title="Empty">Definition</a>: An element
|
|
with no <a href="#NT-content">content</a> is said to be <b>empty</b>.] The representation
|
|
of an empty element is either a start-tag immediately followed by an end-tag,
|
|
or an empty-element tag. [<a name="dt-eetag" id="dt-eetag" title="empty-element tag">Definition</a>: An <b>empty-element
|
|
tag</b> takes a special form:]</p> <h5><a name="IDARY3S" id="IDARY3S" />Tags for Empty Elements</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-EmptyElemTag" id="NT-EmptyElemTag" />[44] </td><td><code>EmptyElemTag</code></td><td> ::= </td><td><code>'<' <a href="#NT-Name">Name</a> (<a href="#NT-S">S</a> <a href="#NT-Attribute">Attribute</a>)* <a href="#NT-S">S</a>? '/>'</code></td><td><a href="#uniqattspec">[WFC: Unique Att Spec]</a></td></tr></tbody></table><p>Empty-element tags <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> be used for any element which has no content, whether
|
|
or not it is declared using the keyword <b>EMPTY</b>. <a title="For interoperability" href="#dt-interop">For
|
|
interoperability</a>, the empty-element tag <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em>
|
|
be used, and <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> only be used, for elements which are declared
|
|
EMPTY.</p><p>Examples of empty elements:</p><div class="exampleInner"><pre><IMG align="left"
|
|
src="http://www.w3.org/Icons/WWW/w3c_home" />
|
|
<br></br>
|
|
<br/></pre></div></div><div class="div2"> <h3><a name="elemdecls" id="elemdecls" />3.2 Element Type Declarations</h3><p>The <a title="Element" href="#dt-element">element</a> structure of an <a title="XML Document" href="#dt-xml-doc">XML document</a> <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em>, for <a title="Validity" href="#dt-valid">validation</a>
|
|
purposes, be constrained using element type and attribute-list declarations.
|
|
An element type declaration constrains the element's <a title="Content" href="#dt-content">content</a>.</p><p>Element type declarations often constrain which element types can appear
|
|
as <a title="Parent/Child" href="#dt-parentchild">children</a> of the element. At user
|
|
option, an XML processor <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> issue a warning when a declaration mentions an
|
|
element type for which no declaration is provided, but this is not an error.</p><p>[<a name="dt-eldecl" id="dt-eldecl" title="Element Type declaration">Definition</a>: An <b>element
|
|
type declaration</b> takes the form:]</p> <h5><a name="IDAV13S" id="IDAV13S" />Element Type Declaration</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-elementdecl" id="NT-elementdecl" />[45] </td><td><code>elementdecl</code></td><td> ::= </td><td><code>'<!ELEMENT' <a href="#NT-S">S</a> <a href="#NT-Name">Name</a> <a href="#NT-S">S</a> <a href="#NT-contentspec">contentspec</a> <a href="#NT-S">S</a>?
|
|
'>'</code></td><td><a href="#EDUnique">[VC: Unique Element Type Declaration]</a></td></tr><tr valign="baseline"><td><a name="NT-contentspec" id="NT-contentspec" />[46] </td><td><code>contentspec</code></td><td> ::= </td><td><code>'EMPTY' | 'ANY' | <a href="#NT-Mixed">Mixed</a>
|
|
| <a href="#NT-children">children</a></code></td></tr></tbody></table><p>where the <a href="#NT-Name">Name</a> gives the element type being declared.</p><div class="constraint"><p class="prefix"><a name="EDUnique" id="EDUnique" /><b>Validity constraint: Unique Element Type Declaration</b></p><p><span class="mustard">An element
|
|
type <em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em></span> be declared more than once.</p></div><p>Examples of element type declarations:</p><div class="exampleInner"><pre><!ELEMENT br EMPTY>
|
|
<!ELEMENT p (#PCDATA|emph)* >
|
|
<!ELEMENT %name.para; %content.para; >
|
|
<!ELEMENT container ANY></pre></div><div class="div3"> <h4><a name="sec-element-content" id="sec-element-content" />3.2.1 Element Content</h4><p>[<a name="dt-elemcontent" id="dt-elemcontent" title="Element content">Definition</a>: An element <a title="Start-Tag" href="#dt-stag">type</a> has <b>element content</b> when elements
|
|
of that type <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> contain only <a title="Parent/Child" href="#dt-parentchild">child</a>
|
|
elements (no character data), optionally separated by white space (characters
|
|
matching the nonterminal <a href="#NT-S">S</a>).] [<a name="dt-content-model" id="dt-content-model" title="Content model">Definition</a>: In this case, the constraint includes a <b>content
|
|
model</b>, a simple grammar governing the allowed types of the
|
|
child elements and the order in which they are allowed to appear.]
|
|
The grammar is built on content particles (<a href="#NT-cp">cp</a>s), which
|
|
consist of names, choice lists of content particles, or sequence lists of
|
|
content particles:</p> <h5><a name="IDAP53S" id="IDAP53S" />Element-content Models</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-children" id="NT-children" />[47] </td><td><code>children</code></td><td> ::= </td><td><code>(<a href="#NT-choice">choice</a> | <a href="#NT-seq">seq</a>)
|
|
('?' | '*' | '+')?</code></td></tr><tr valign="baseline"><td><a name="NT-cp" id="NT-cp" />[48] </td><td><code>cp</code></td><td> ::= </td><td><code>(<a href="#NT-Name">Name</a> | <a href="#NT-choice">choice</a>
|
|
| <a href="#NT-seq">seq</a>) ('?' | '*' | '+')?</code></td></tr><tr valign="baseline"><td><a name="NT-choice" id="NT-choice" />[49] </td><td><code>choice</code></td><td> ::= </td><td><code>'(' <a href="#NT-S">S</a>? <a href="#NT-cp">cp</a> ( <a href="#NT-S">S</a>? '|' <a href="#NT-S">S</a>? <a href="#NT-cp">cp</a> )+ <a href="#NT-S">S</a>? ')'</code></td><td><a href="#vc-PEinGroup">[VC: Proper Group/PE Nesting]</a></td></tr><tr valign="baseline"><td><a name="NT-seq" id="NT-seq" />[50] </td><td><code>seq</code></td><td> ::= </td><td><code>'(' <a href="#NT-S">S</a>? <a href="#NT-cp">cp</a> ( <a href="#NT-S">S</a>? ',' <a href="#NT-S">S</a>? <a href="#NT-cp">cp</a> )* <a href="#NT-S">S</a>? ')'</code></td><td><a href="#vc-PEinGroup">[VC: Proper Group/PE Nesting]</a></td></tr></tbody></table><p>where each <a href="#NT-Name">Name</a> is the type of an element which
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> appear as a <a title="Parent/Child" href="#dt-parentchild">child</a>. Any content
|
|
particle in a choice list <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> appear in the <a title="Element content" href="#dt-elemcontent">element
|
|
content</a> at the location where the choice list appears in the grammar;
|
|
content particles occurring in a sequence list <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> each appear in the <a title="Element content" href="#dt-elemcontent">element content</a> in the order given in the list.
|
|
The optional character following a name or list governs whether the element
|
|
or the content particles in the list may occur one or more (<code>+</code>),
|
|
zero or more (<code>*</code>), or zero or one times (<code>?</code>). The
|
|
absence of such an operator means that the element or content particle <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em>
|
|
appear exactly once. This syntax and meaning are identical to those used in
|
|
the productions in this specification.</p><p>The content of an element matches a content model if and only if it is
|
|
possible to trace out a path through the content model, obeying the sequence,
|
|
choice, and repetition operators and matching each element in the content
|
|
against an element type in the content model. <a title="For Compatibility" href="#dt-compat">For
|
|
compatibility</a>, it is an error if <span>the content model
|
|
allows an element to match more than one occurrence of an element type in the
|
|
content model</span>. For more information, see <a href="#determinism"><b>D Deterministic Content Models</b></a>.</p><div class="constraint"><p class="prefix"><a name="vc-PEinGroup" id="vc-PEinGroup" /><b>Validity constraint: Proper Group/PE Nesting</b></p><p>Parameter-entity <a title="Replacement Text" href="#dt-repltext">replacement text</a> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be properly nested with parenthesized
|
|
groups. That is to say, if either of the opening or closing parentheses in
|
|
a <a href="#NT-choice">choice</a>, <a href="#NT-seq">seq</a>, or <a href="#NT-Mixed">Mixed</a>
|
|
construct is contained in the replacement text for a <a title="Parameter-entity reference" href="#dt-PERef">parameter
|
|
entity</a>, both <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be contained in the same replacement text.</p><p><a title="For interoperability" href="#dt-interop">For interoperability</a>, if a parameter-entity reference
|
|
appears in a <a href="#NT-choice">choice</a>, <a href="#NT-seq">seq</a>, or <a href="#NT-Mixed">Mixed</a> construct, its replacement text <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> contain at
|
|
least one non-blank character, and neither the first nor last non-blank character
|
|
of the replacement text <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> be a connector (<code>|</code> or <code>,</code>).</p></div><p>Examples of element-content models:</p><div class="exampleInner"><pre><!ELEMENT spec (front, body, back?)>
|
|
<!ELEMENT div1 (head, (p | list | note)*, div2*)>
|
|
<!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*></pre></div></div><div class="div3"> <h4><a name="sec-mixed-content" id="sec-mixed-content" />3.2.2 Mixed Content</h4><p>[<a name="dt-mixed" id="dt-mixed" title="Mixed Content">Definition</a>: An element <a title="Start-Tag" href="#dt-stag">type</a>
|
|
has <b>mixed content</b> when elements of that type <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> contain character
|
|
data, optionally interspersed with <a title="Parent/Child" href="#dt-parentchild">child</a>
|
|
elements.] In this case, the types of the child elements <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> be constrained,
|
|
but not their order or their number of occurrences:</p> <h5><a name="IDAUHCU" id="IDAUHCU" />Mixed-content Declaration</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-Mixed" id="NT-Mixed" />[51] </td><td><code>Mixed</code></td><td> ::= </td><td><code>'(' <a href="#NT-S">S</a>? '#PCDATA' (<a href="#NT-S">S</a>?
|
|
'|' <a href="#NT-S">S</a>? <a href="#NT-Name">Name</a>)* <a href="#NT-S">S</a>?
|
|
')*' </code></td></tr><tr valign="baseline"><td /><td /><td /><td><code>| '(' <a href="#NT-S">S</a>? '#PCDATA' <a href="#NT-S">S</a>? ')' </code></td><td><a href="#vc-PEinGroup">[VC: Proper Group/PE Nesting]</a></td></tr><tr valign="baseline"><td /><td /><td /><td /><td><a href="#vc-MixedChildrenUnique">[VC: No Duplicate Types]</a></td></tr></tbody></table><p>where the <a href="#NT-Name">Name</a>s give the types of elements that
|
|
may appear as children. The
|
|
keyword <b>#PCDATA</b> derives historically from the term "parsed
|
|
character data."</p><div class="constraint"><p class="prefix"><a name="vc-MixedChildrenUnique" id="vc-MixedChildrenUnique" /><b>Validity constraint: No Duplicate Types</b></p><p>The
|
|
same name <em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em> appear more than once in a single mixed-content declaration.</p></div><p>Examples of mixed content declarations:</p><div class="exampleInner"><pre><!ELEMENT p (#PCDATA|a|ul|b|i|em)*>
|
|
<!ELEMENT p (#PCDATA | %font; | %phrase; | %special; | %form;)* >
|
|
<!ELEMENT b (#PCDATA)></pre></div></div></div><div class="div2"> <h3><a name="attdecls" id="attdecls" />3.3 Attribute-List Declarations</h3><p><a title="Attribute" href="#dt-attr">Attributes</a> are used to associate name-value
|
|
pairs with <a title="Element" href="#dt-element">elements</a>. Attribute specifications
|
|
<span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em> appear outside of</span> <a title="Start-Tag" href="#dt-stag">start-tags</a> and <a title="empty-element tag" href="#dt-eetag">empty-element tags</a>; thus, the productions used to
|
|
recognize them appear in <a href="#sec-starttags"><b>3.1 Start-Tags, End-Tags, and Empty-Element Tags</b></a>. Attribute-list declarations
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> be used:</p><ul><li><p>To define the set of attributes pertaining to a given element type.</p></li><li><p>To establish type constraints for these attributes.</p></li><li><p>To provide <a title="Attribute Default" href="#dt-default">default values</a> for
|
|
attributes.</p></li></ul><p>[<a name="dt-attdecl" id="dt-attdecl" title="Attribute-List Declaration">Definition</a>: <b>Attribute-list
|
|
declarations</b> specify the name, data type, and default value (if any)
|
|
of each attribute associated with a given element type:]</p> <h5><a name="IDADMCU" id="IDADMCU" />Attribute-list Declaration</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-AttlistDecl" id="NT-AttlistDecl" />[52] </td><td><code>AttlistDecl</code></td><td> ::= </td><td><code>'<!ATTLIST' <a href="#NT-S">S</a> <a href="#NT-Name">Name</a> <a href="#NT-AttDef">AttDef</a>* <a href="#NT-S">S</a>? '>'</code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-AttDef" id="NT-AttDef" />[53] </td><td><code>AttDef</code></td><td> ::= </td><td><code><a href="#NT-S">S</a> <a href="#NT-Name">Name</a> <a href="#NT-S">S</a> <a href="#NT-AttType">AttType</a> <a href="#NT-S">S</a> <a href="#NT-DefaultDecl">DefaultDecl</a></code></td></tr></tbody></table><p>The <a href="#NT-Name">Name</a> in the <a href="#NT-AttlistDecl">AttlistDecl</a>
|
|
rule is the type of an element. At user option, an XML processor <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> issue
|
|
a warning if attributes are declared for an element type not itself declared,
|
|
but this is not an error. The <a href="#NT-Name">Name</a> in the <a href="#NT-AttDef">AttDef</a>
|
|
rule is the name of the attribute.</p><p>When more than one <a href="#NT-AttlistDecl">AttlistDecl</a> is provided
|
|
for a given element type, the contents of all those provided are merged. When
|
|
more than one definition is provided for the same attribute of a given element
|
|
type, the first declaration is binding and later declarations are ignored. <a title="For interoperability" href="#dt-interop">For interoperability,</a> writers of DTDs <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> choose
|
|
to provide at most one attribute-list declaration for a given element type,
|
|
at most one attribute definition for a given attribute name in an attribute-list
|
|
declaration, and at least one attribute definition in each attribute-list
|
|
declaration. For interoperability, an XML processor <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> at user option
|
|
issue a warning when more than one attribute-list declaration is provided
|
|
for a given element type, or more than one attribute definition is provided
|
|
for a given attribute, but this is not an error.</p><div class="div3"> <h4><a name="sec-attribute-types" id="sec-attribute-types" />3.3.1 Attribute Types</h4><p>XML attribute types are of three kinds: a string type, a set of tokenized
|
|
types, and enumerated types. The string type may take any literal string as
|
|
a value; the tokenized types have varying lexical and semantic constraints.
|
|
The validity constraints noted in the grammar are applied after the attribute
|
|
value has been normalized as described in <span><a href="#AVNormalize"><b>3.3.3 Attribute-Value Normalization</b></a></span>.</p> <h5><a name="IDAPPCU" id="IDAPPCU" />Attribute Types</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-AttType" id="NT-AttType" />[54] </td><td><code>AttType</code></td><td> ::= </td><td><code><a href="#NT-StringType">StringType</a> | <a href="#NT-TokenizedType">TokenizedType</a>
|
|
| <a href="#NT-EnumeratedType">EnumeratedType</a></code></td></tr><tr valign="baseline"><td><a name="NT-StringType" id="NT-StringType" />[55] </td><td><code>StringType</code></td><td> ::= </td><td><code>'CDATA'</code></td></tr><tr valign="baseline"><td><a name="NT-TokenizedType" id="NT-TokenizedType" />[56] </td><td><code>TokenizedType</code></td><td> ::= </td><td><code>'ID'</code></td><td><a href="#id">[VC: ID]</a></td></tr><tr valign="baseline"><td /><td /><td /><td /><td><a href="#one-id-per-el">[VC: One ID per Element Type]</a></td></tr><tr valign="baseline"><td /><td /><td /><td /><td><a href="#id-default">[VC: ID Attribute Default]</a></td></tr><tr valign="baseline"><td /><td /><td /><td><code>| 'IDREF'</code></td><td><a href="#idref">[VC: IDREF]</a></td></tr><tr valign="baseline"><td /><td /><td /><td><code>| 'IDREFS'</code></td><td><a href="#idref">[VC: IDREF]</a></td></tr><tr valign="baseline"><td /><td /><td /><td><code>| 'ENTITY'</code></td><td><a href="#entname">[VC: Entity Name]</a></td></tr><tr valign="baseline"><td /><td /><td /><td><code>| 'ENTITIES'</code></td><td><a href="#entname">[VC: Entity Name]</a></td></tr><tr valign="baseline"><td /><td /><td /><td><code>| 'NMTOKEN'</code></td><td><a href="#nmtok">[VC: Name Token]</a></td></tr><tr valign="baseline"><td /><td /><td /><td><code>| 'NMTOKENS'</code></td><td><a href="#nmtok">[VC: Name Token]</a></td></tr></tbody></table><div class="constraint"><p class="prefix"><a name="id" id="id" /><b>Validity constraint: ID</b></p><p>Values of type <b>ID</b> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> match the <a href="#NT-Name">Name</a> production. A name <em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em> appear more than once
|
|
in an XML document as a value of this type; i.e., ID values <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> uniquely
|
|
identify the elements which bear them.</p></div><div class="constraint"><p class="prefix"><a name="one-id-per-el" id="one-id-per-el" /><b>Validity constraint: One ID per Element Type</b></p><p><span class="mustard">An element
|
|
type <em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em></span> have more than one ID attribute specified.</p></div><div class="constraint"><p class="prefix"><a name="id-default" id="id-default" /><b>Validity constraint: ID Attribute Default</b></p><p>An ID attribute
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> have a declared default of <b>#IMPLIED</b> or <b>#REQUIRED</b>.</p></div><div class="constraint"><p class="prefix"><a name="idref" id="idref" /><b>Validity constraint: IDREF</b></p><p>Values of type <b>IDREF</b> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em>
|
|
match the <a href="#NT-Name">Name</a> production, and values of type <b>IDREFS</b> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> match <a href="#NT-Names">Names</a>; each <a href="#NT-Name">Name</a> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> match the value of an ID attribute on some element in the XML document;
|
|
i.e. <b>IDREF</b> values <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> match the value of some ID attribute.</p></div><div class="constraint"><p class="prefix"><a name="entname" id="entname" /><b>Validity constraint: Entity Name</b></p><p>Values of type <b>ENTITY</b> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> match the <a href="#NT-Name">Name</a> production, values of type <b>ENTITIES</b> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> match <a href="#NT-Names">Names</a>; each <a href="#NT-Name">Name</a> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> match the name of an <a title="Unparsed Entity" href="#dt-unparsed">unparsed entity</a>
|
|
declared in the <a title="Document Type Declaration" href="#dt-doctype">DTD</a>.</p></div><div class="constraint"><p class="prefix"><a name="nmtok" id="nmtok" /><b>Validity constraint: Name Token</b></p><p>Values of type <b>NMTOKEN</b> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> match the <a href="#NT-Nmtoken">Nmtoken</a> production; values of type <b>NMTOKENS</b> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> match <a href="#NT-Nmtokens">Nmtokens</a>.</p></div><p>[<a name="dt-enumerated" id="dt-enumerated" title="Enumerated Attribute
Values">Definition</a>: <b>Enumerated attributes</b> <span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em></span> take one of a list of values
|
|
provided in the declaration]. There are two kinds of enumerated types:</p> <h5><a name="IDAHXCU" id="IDAHXCU" />Enumerated Attribute Types</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-EnumeratedType" id="NT-EnumeratedType" />[57] </td><td><code>EnumeratedType</code></td><td> ::= </td><td><code><a href="#NT-NotationType">NotationType</a>
|
|
| <a href="#NT-Enumeration">Enumeration</a></code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-NotationType" id="NT-NotationType" />[58] </td><td><code>NotationType</code></td><td> ::= </td><td><code>'NOTATION' <a href="#NT-S">S</a> '(' <a href="#NT-S">S</a>? <a href="#NT-Name">Name</a> (<a href="#NT-S">S</a>? '|' <a href="#NT-S">S</a>? <a href="#NT-Name">Name</a>)* <a href="#NT-S">S</a>? ')' </code></td><td><a href="#notatn">[VC: Notation Attributes]</a></td></tr><tr valign="baseline"><td /><td /><td /><td /><td><a href="#OneNotationPer">[VC: One Notation Per Element Type]</a></td></tr><tr valign="baseline"><td /><td /><td /><td /><td><a href="#NoNotationEmpty">[VC: No Notation on Empty Element]</a></td></tr><tr valign="baseline"><td /><td /><td /><td /><td><a href="#NoDuplicateTokens">[VC: No Duplicate
|
|
Tokens]</a></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-Enumeration" id="NT-Enumeration" />[59] </td><td><code>Enumeration</code></td><td> ::= </td><td><code>'(' <a href="#NT-S">S</a>? <a href="#NT-Nmtoken">Nmtoken</a>
|
|
(<a href="#NT-S">S</a>? '|' <a href="#NT-S">S</a>? <a href="#NT-Nmtoken">Nmtoken</a>)* <a href="#NT-S">S</a>? ')'</code></td><td><a href="#enum">[VC: Enumeration]</a></td></tr><tr valign="baseline"><td /><td /><td /><td /><td><a href="#NoDuplicateTokens">[VC: No Duplicate
|
|
Tokens]</a></td></tr></tbody></table><p>A <b>NOTATION</b> attribute identifies a <a title="Notation" href="#dt-notation">notation</a>,
|
|
declared in the DTD with associated system and/or public identifiers, to be
|
|
used in interpreting the element to which the attribute is attached.</p><div class="constraint"><p class="prefix"><a name="notatn" id="notatn" /><b>Validity constraint: Notation Attributes</b></p><p>Values of this type
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> match one of the <a href="#Notations"><cite>notation</cite></a> names
|
|
included in the declaration; all notation names in the declaration <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be
|
|
declared.</p></div><div class="constraint"><p class="prefix"><a name="OneNotationPer" id="OneNotationPer" /><b>Validity constraint: One Notation Per Element Type</b></p><p><span class="mustard">An element type <em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em></span> have more than one <b>NOTATION</b>
|
|
attribute specified.</p></div><div class="constraint"><p class="prefix"><a name="NoNotationEmpty" id="NoNotationEmpty" /><b>Validity constraint: No Notation on Empty Element</b></p><p><a title="For Compatibility" href="#dt-compat">For compatibility</a>,
|
|
an attribute of type <b>NOTATION</b> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em> be declared on an element
|
|
declared <b>EMPTY</b>.</p></div><div class="constraint"><p class="prefix"><a name="NoDuplicateTokens" id="NoDuplicateTokens" /><b>Validity constraint: No Duplicate
|
|
Tokens</b></p><p>The notation names in a single <a href="#NT-NotationType">NotationType</a>
|
|
attribute declaration, as well as the <a href="#NT-Nmtoken">NmToken</a>s in a single
|
|
<a href="#NT-Enumeration">Enumeration</a> attribute declaration, <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> all be distinct.</p></div><div class="constraint"><p class="prefix"><a name="enum" id="enum" /><b>Validity constraint: Enumeration</b></p><p>Values of this type <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> match
|
|
one of the <a href="#NT-Nmtoken">Nmtoken</a> tokens in the declaration.</p></div><p><a title="For interoperability" href="#dt-interop">For interoperability,</a> the same <a href="#NT-Nmtoken">Nmtoken</a> <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD NOT</em> occur more than once in the enumerated
|
|
attribute types of a single element type.</p></div><div class="div3"> <h4><a name="sec-attr-defaults" id="sec-attr-defaults" />3.3.2 Attribute Defaults</h4><p>An <a title="Attribute-List Declaration" href="#dt-attdecl">attribute declaration</a> provides information
|
|
on whether the attribute's presence is <em class="rfc2119" title="Keyword in RFC 2119 context">REQUIRED</em>, and if not, how an XML processor
|
|
<span>is
|
|
to</span> react if a declared attribute is absent in a document.</p> <h5><a name="IDAR4CU" id="IDAR4CU" />Attribute Defaults</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-DefaultDecl" id="NT-DefaultDecl" />[60] </td><td><code>DefaultDecl</code></td><td> ::= </td><td><code>'#REQUIRED' | '#IMPLIED' </code></td></tr><tr valign="baseline"><td /><td /><td /><td><code>| (('#FIXED' S)? <a href="#NT-AttValue">AttValue</a>)</code></td><td><a href="#RequiredAttr">[VC: Required Attribute]</a></td></tr><tr valign="baseline"><td /><td /><td /><td /><td><a href="#defattrvalid">[VC: Attribute
|
|
Default Value Syntactically Correct]</a></td></tr><tr valign="baseline"><td /><td /><td /><td /><td><a href="#CleanAttrVals">[WFC: No < in Attribute Values]</a></td></tr><tr valign="baseline"><td /><td /><td /><td /><td><a href="#FixedAttr">[VC: Fixed Attribute Default]</a></td></tr></tbody></table><p>In an attribute declaration, <b>#REQUIRED</b> means that the attribute
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> always be provided, <b>#IMPLIED</b> that no default value is provided.
|
|
[<a name="dt-default" id="dt-default" title="Attribute Default">Definition</a>: If
|
|
the declaration is neither <b>#REQUIRED</b> nor <b>#IMPLIED</b>, then
|
|
the <a href="#NT-AttValue">AttValue</a> value contains the declared <b>default</b>
|
|
value; the <b>#FIXED</b> keyword states that the attribute <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> always have
|
|
the default value.
|
|
When an XML processor encounters
|
|
an <span>element
|
|
without a specification for an attribute for which it has read a default
|
|
value declaration, it <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> report the attribute with the declared default
|
|
value to the application</span>.]</p><div class="constraint"><p class="prefix"><a name="RequiredAttr" id="RequiredAttr" /><b>Validity constraint: Required Attribute</b></p><p>If the default
|
|
declaration is the keyword <b>#REQUIRED</b>, then the attribute <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be
|
|
specified for all elements of the type in the attribute-list declaration.</p></div><div class="constraint"><p class="prefix"><a name="defattrvalid" id="defattrvalid" /><b>Validity constraint: <span>Attribute
|
|
Default Value Syntactically Correct</span></b></p><p>The declared default value <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> meet the <span>syntactic</span>
|
|
constraints of the declared attribute type.</p><p>Note that only the
|
|
syntactic constraints of the type are required here; other constraints (e.g.
|
|
that the value be the name of a declared unparsed entity, for an attribute of
|
|
type ENTITY) may come into play if the declared default value is actually used
|
|
(an element without a specification for this attribute occurs).</p></div><div class="constraint"><p class="prefix"><a name="FixedAttr" id="FixedAttr" /><b>Validity constraint: Fixed Attribute Default</b></p><p>If an attribute
|
|
has a default value declared with the <b>#FIXED</b> keyword, instances of
|
|
that attribute <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> match the default value.</p></div><p>Examples of attribute-list declarations:</p><div class="exampleInner"><pre><!ATTLIST termdef
|
|
id ID #REQUIRED
|
|
name CDATA #IMPLIED>
|
|
<!ATTLIST list
|
|
type (bullets|ordered|glossary) "ordered">
|
|
<!ATTLIST form
|
|
method CDATA #FIXED "POST"></pre></div></div><div class="div3"> <h4><a name="AVNormalize" id="AVNormalize" />3.3.3 Attribute-Value Normalization</h4><p>Before the value of an attribute is passed to the application or checked
|
|
for validity, the XML processor <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> normalize the attribute value by applying
|
|
the algorithm below, or by using some other method such that the value passed
|
|
to the application is the same as that produced by the algorithm.</p><ol type="1"><li><p>All line breaks <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> have been normalized on input to #xA as described
|
|
in <a href="#sec-line-ends"><b>2.11 End-of-Line Handling</b></a>, so the rest of this algorithm operates
|
|
on text normalized in this way.</p></li><li><p>Begin with a normalized value consisting of the empty string.</p></li><li><p>For each character, entity reference, or character reference in the
|
|
unnormalized attribute value, beginning with the first and continuing to the
|
|
last, do the following:</p><ul><li><p>For a character reference, append the referenced character to the
|
|
normalized value.</p></li><li><p>For an entity reference, recursively apply step 3 of this algorithm
|
|
to the replacement text of the entity.</p></li><li><p>For a white space character (#x20, #xD, #xA, #x9), append a space
|
|
character (#x20) to the normalized value.</p></li><li><p>For another character, append the character to the normalized value.</p></li></ul></li></ol><p>If the attribute type is not CDATA, then the XML processor <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> further
|
|
process the normalized attribute value by discarding any leading and trailing
|
|
space (#x20) characters, and by replacing sequences of space (#x20) characters
|
|
by a single space (#x20) character.</p><p>Note that if the unnormalized attribute value contains a character reference
|
|
to a white space character other than space (#x20), the normalized value contains
|
|
the referenced character itself (#xD, #xA or #x9). This contrasts with the
|
|
case where the unnormalized value contains a white space character (not a
|
|
reference), which is replaced with a space character (#x20) in the normalized
|
|
value and also contrasts with the case where the unnormalized value contains
|
|
an entity reference whose replacement text contains a white space character;
|
|
being recursively processed, the white space character is replaced with a
|
|
space character (#x20) in the normalized value.</p><p>All attributes for which no declaration has been read <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> be treated
|
|
by a non-validating processor as if declared <b>CDATA</b>.</p><p>It
|
|
is an error if an
|
|
<span><a title="Attribute Value" href="#dt-attrval">attribute
|
|
value</a> contains a <a title="Entity Reference" href="#dt-entref">reference</a> to an
|
|
entity for which no declaration has been read.</span></p><p>Following are examples of attribute normalization. Given the following
|
|
declarations:</p><div class="exampleInner"><pre><!ENTITY d "&#xD;">
|
|
<!ENTITY a "&#xA;">
|
|
<!ENTITY da "&#xD;&#xA;"></pre></div><p>the attribute specifications in the left column below would be normalized
|
|
to the character sequences of the middle column if the attribute <code>a</code>
|
|
is declared <b>NMTOKENS</b> and to those of the right columns if <code>a</code>
|
|
is declared <b>CDATA</b>.</p><table border="1" frame="border" summary="Attribute normalization summary"><thead><tr><th rowspan="1" colspan="1">Attribute specification</th><th rowspan="1" colspan="1">a is NMTOKENS</th><th rowspan="1" colspan="1">a is CDATA</th></tr></thead><tbody><tr><td rowspan="1" colspan="1"><div class="exampleInner"><pre>a="
|
|
xyz"</pre></div></td><td rowspan="1" colspan="1"><div class="exampleInner"><pre>x y z</pre></div></td><td rowspan="1" colspan="1"><div class="exampleInner"><pre>#x20 #x20 x y z</pre></div></td></tr><tr><td rowspan="1" colspan="1"><div class="exampleInner"><pre>a="&d;&d;A&a;<span>&#x20;</span>&a;B&da;"</pre></div></td><td rowspan="1" colspan="1"><div class="exampleInner"><pre>A #x20 B</pre></div></td><td rowspan="1" colspan="1"><div class="exampleInner"><pre>#x20 #x20 A #x20 <span>#x20</span> #x20 B #x20 #x20</pre></div></td></tr><tr><td rowspan="1" colspan="1"><div class="exampleInner"><pre>a=
|
|
"&#xd;&#xd;A&#xa;&#xa;B&#xd;&#xa;"</pre></div></td><td rowspan="1" colspan="1"><div class="exampleInner"><pre>#xD #xD A #xA #xA B #xD #xA</pre></div></td><td rowspan="1" colspan="1"><div class="exampleInner"><pre>#xD #xD A #xA #xA B #xD #xA</pre></div></td></tr></tbody></table><p>Note that the last example is invalid (but well-formed) if <code>a</code>
|
|
is declared to be of type <b>NMTOKENS</b>.</p></div></div><div class="div2"> <h3><a name="sec-condition-sect" id="sec-condition-sect" />3.4 Conditional Sections</h3><p>[<a name="dt-cond-section" id="dt-cond-section" title="conditional section">Definition</a>: <b>Conditional
|
|
sections</b> are portions of the <a title="Document Type Declaration" href="#dt-doctype">document type
|
|
declaration external subset</a> <span>or
|
|
of external parameter entities </span>which are included in, or excluded from,
|
|
the logical structure of the DTD based on the keyword which governs them.]</p> <h5><a name="IDAMHDU" id="IDAMHDU" />Conditional Section</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-conditionalSect" id="NT-conditionalSect" />[61] </td><td><code>conditionalSect</code></td><td> ::= </td><td><code><a href="#NT-includeSect">includeSect</a> | <a href="#NT-ignoreSect">ignoreSect</a></code></td></tr><tr valign="baseline"><td><a name="NT-includeSect" id="NT-includeSect" />[62] </td><td><code>includeSect</code></td><td> ::= </td><td><code>'<![' S? 'INCLUDE' S? '[' <a href="#NT-extSubsetDecl">extSubsetDecl</a>
|
|
']]>' </code></td><td><a href="#condsec-nesting">[VC: Proper Conditional Section/PE Nesting]</a></td></tr><tr valign="baseline"><td><a name="NT-ignoreSect" id="NT-ignoreSect" />[63] </td><td><code>ignoreSect</code></td><td> ::= </td><td><code>'<![' S? 'IGNORE' S? '[' <a href="#NT-ignoreSectContents">ignoreSectContents</a>*
|
|
']]>'</code></td><td><a href="#condsec-nesting">[VC: Proper Conditional Section/PE Nesting]</a></td></tr><tr valign="baseline"><td><a name="NT-ignoreSectContents" id="NT-ignoreSectContents" />[64] </td><td><code>ignoreSectContents</code></td><td> ::= </td><td><code><a href="#NT-Ignore">Ignore</a> ('<![' <a href="#NT-ignoreSectContents">ignoreSectContents</a> ']]>' <a href="#NT-Ignore">Ignore</a>)*</code></td></tr><tr valign="baseline"><td><a name="NT-Ignore" id="NT-Ignore" />[65] </td><td><code>Ignore</code></td><td> ::= </td><td><code><a href="#NT-Char">Char</a>* - (<a href="#NT-Char">Char</a>*
|
|
('<![' | ']]>') <a href="#NT-Char">Char</a>*) </code></td></tr></tbody></table><div class="constraint"><p class="prefix"><a name="condsec-nesting" id="condsec-nesting" /><b>Validity constraint: Proper Conditional Section/PE Nesting</b></p><p>If any of the "<code><![</code>",
|
|
"<code>[</code>", or "<code>]]></code>" of a conditional section is contained
|
|
in the replacement text for a parameter-entity reference, all of them <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em>
|
|
be contained in the same replacement text.</p></div><p>Like the internal and external DTD subsets, a conditional section may contain
|
|
one or more complete declarations, comments, processing instructions, or nested
|
|
conditional sections, intermingled with white space.</p><p>If the keyword of the conditional section is <b>INCLUDE</b>, then the
|
|
contents of the conditional section <span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be considered</span> part of the DTD. If the keyword of
|
|
the conditional section is <b>IGNORE</b>, then the contents of the conditional
|
|
section <span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be considered as</span> not logically part of the DTD.
|
|
If a conditional section with a keyword of <b>INCLUDE</b> occurs within
|
|
a larger conditional section with a keyword of <b>IGNORE</b>, both the outer
|
|
and the inner conditional sections <span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be</span> ignored. The contents
|
|
of an ignored conditional section <span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be</span> parsed by ignoring all characters after
|
|
the "<code>[</code>" following the keyword, except conditional section starts
|
|
"<code><![</code>" and ends "<code>]]></code>", until the matching conditional
|
|
section end is found. Parameter entity references <span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em> be</span> recognized in this
|
|
process.</p><p>If the keyword of the conditional section is a parameter-entity reference,
|
|
the parameter entity <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be replaced by its content before the processor
|
|
decides whether to include or ignore the conditional section.</p><p>An example:</p><div class="exampleInner"><pre><!ENTITY % draft 'INCLUDE' >
|
|
<!ENTITY % final 'IGNORE' >
|
|
<![%draft;[
|
|
<!ELEMENT book (comments*, title, body, supplements?)>
|
|
]]>
|
|
<![%final;[
|
|
<!ELEMENT book (title, body, supplements?)>
|
|
]]></pre></div></div></div><div class="div1"> <h2><a name="sec-physical-struct" id="sec-physical-struct" />4 Physical Structures</h2><p>[<a name="dt-entity" id="dt-entity" title="Entity">Definition</a>: An XML document may consist of one
|
|
or many storage units. These
|
|
are called <b>entities</b>; they all have <b>content</b> and are
|
|
all (except for the <a title="Document Entity" href="#dt-docent">document entity</a> and
|
|
the <a title="Document Type Declaration" href="#dt-doctype">external DTD subset</a>) identified by
|
|
entity <b>name</b>.] Each XML document has one entity
|
|
called the <a title="Document Entity" href="#dt-docent">document entity</a>, which serves
|
|
as the starting point for the <a title="XML Processor" href="#dt-xml-proc">XML processor</a>
|
|
and may contain the whole document.</p><p>Entities may be either parsed or unparsed. [<a name="dt-parsedent" id="dt-parsedent" title="Text Entity">Definition</a>: The contents of a <b>parsed
|
|
entity</b> are referred to as its <a title="Replacement Text" href="#dt-repltext">replacement
|
|
text</a>; this <a title="Text" href="#dt-text">text</a> is considered an
|
|
integral part of the document.]</p><p>[<a name="dt-unparsed" id="dt-unparsed" title="Unparsed Entity">Definition</a>: An <b>unparsed entity</b>
|
|
is a resource whose contents may or may not be <a title="Text" href="#dt-text">text</a>,
|
|
and if text, may
|
|
be other than XML. Each unparsed entity has an associated <a title="Notation" href="#dt-notation">notation</a>, identified by name. Beyond a requirement
|
|
that an XML processor make the identifiers for the entity and notation available
|
|
to the application, XML places no constraints on the contents of unparsed
|
|
entities.]</p><p>Parsed entities are invoked by name using entity references; unparsed entities
|
|
by name, given in the value of <b>ENTITY</b> or <b>ENTITIES</b> attributes.</p><p>[<a name="gen-entity" id="gen-entity" title="general entity">Definition</a>: <b>General entities</b>
|
|
are entities for use within the document content. In this specification, general
|
|
entities are sometimes referred to with the unqualified term <em>entity</em>
|
|
when this leads to no ambiguity.] [<a name="dt-PE" id="dt-PE" title="Parameter entity">Definition</a>: <b>Parameter
|
|
entities</b> are parsed entities for use within the DTD.]
|
|
These two types of entities use different forms of reference and are recognized
|
|
in different contexts. Furthermore, they occupy different namespaces; a parameter
|
|
entity and a general entity with the same name are two distinct entities.</p><div class="div2"> <h3><a name="sec-references" id="sec-references" />4.1 Character and Entity References</h3><p>[<a name="dt-charref" id="dt-charref" title="Character Reference">Definition</a>: A <b>character
|
|
reference</b> refers to a specific character in the ISO/IEC 10646 character
|
|
set, for example one not directly accessible from available input devices.]</p> <h5><a name="IDAFYDU" id="IDAFYDU" />Character Reference</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-CharRef" id="NT-CharRef" />[66] </td><td><code>CharRef</code></td><td> ::= </td><td><code>'&#' [0-9]+ ';' </code></td></tr><tr valign="baseline"><td /><td /><td /><td><code>| '&#x' [0-9a-fA-F]+ ';'</code></td><td><a href="#wf-Legalchar">[WFC: Legal Character]</a></td></tr></tbody></table><div class="constraint"><p class="prefix"><a name="wf-Legalchar" id="wf-Legalchar" /><b>Well-formedness constraint: Legal Character</b></p><p>Characters referred
|
|
to using character references <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> match the production for <a href="#NT-Char">Char</a>.</p></div><p>If the character reference begins with "<code>&#x</code>",
|
|
the digits and letters up to the terminating <code>;</code> provide a hexadecimal
|
|
representation of the character's code point in ISO/IEC 10646. If it begins
|
|
just with "<code>&#</code>", the digits up to the terminating <code>;</code>
|
|
provide a decimal representation of the character's code point.</p><p>[<a name="dt-entref" id="dt-entref" title="Entity Reference">Definition</a>: An <b>entity reference</b>
|
|
refers to the content of a named entity.] [<a name="dt-GERef" id="dt-GERef" title="General Entity Reference">Definition</a>: References to parsed general entities use
|
|
ampersand (<code>&</code>) and semicolon (<code>;</code>) as delimiters.] [<a name="dt-PERef" id="dt-PERef" title="Parameter-entity reference">Definition</a>: <b>Parameter-entity references</b>
|
|
use percent-sign (<code>%</code>) and semicolon (<code>;</code>) as delimiters.]</p> <h5><a name="IDAS0DU" id="IDAS0DU" />Entity Reference</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-Reference" id="NT-Reference" />[67] </td><td><code>Reference</code></td><td> ::= </td><td><code><a href="#NT-EntityRef">EntityRef</a> | <a href="#NT-CharRef">CharRef</a></code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-EntityRef" id="NT-EntityRef" />[68] </td><td><code>EntityRef</code></td><td> ::= </td><td><code>'&' <a href="#NT-Name">Name</a> ';'</code></td><td><a href="#wf-entdeclared">[WFC: Entity Declared]</a></td></tr><tr valign="baseline"><td /><td /><td /><td /><td><a href="#vc-entdeclared">[VC: Entity Declared]</a></td></tr><tr valign="baseline"><td /><td /><td /><td /><td><a href="#textent">[WFC: Parsed Entity]</a></td></tr><tr valign="baseline"><td /><td /><td /><td /><td><a href="#norecursion">[WFC: No Recursion]</a></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-PEReference" id="NT-PEReference" />[69] </td><td><code>PEReference</code></td><td> ::= </td><td><code>'%' <a href="#NT-Name">Name</a> ';'</code></td><td><a href="#vc-entdeclared">[VC: Entity Declared]</a></td></tr><tr valign="baseline"><td /><td /><td /><td /><td><a href="#norecursion">[WFC: No Recursion]</a></td></tr><tr valign="baseline"><td /><td /><td /><td /><td><a href="#indtd">[WFC: In DTD]</a></td></tr></tbody></table><div class="constraint"><p class="prefix"><a name="wf-entdeclared" id="wf-entdeclared" /><b>Well-formedness constraint: Entity Declared</b></p><p>In a document
|
|
without any DTD, a document with only an internal DTD subset which contains
|
|
no parameter entity references, or a document with "<code>standalone='yes'</code>", for
|
|
an entity reference that does not occur within the external subset or a parameter
|
|
entity, the <a href="#NT-Name">Name</a> given in the entity reference <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> <a title="match" href="#dt-match">match</a> that in an <a href="#sec-entity-decl"><cite>entity
|
|
declaration</cite></a> that does not occur within the external subset or a
|
|
parameter entity, except that well-formed documents need not declare
|
|
any of the following entities: <code>amp</code>,
|
|
<code>lt</code>,
|
|
<code>gt</code>,
|
|
<code>apos</code>,
|
|
<code>quot</code>. The
|
|
declaration of a general entity <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> precede any reference to it which appears
|
|
in a default value in an attribute-list declaration.</p><p><span>Note
|
|
that non-validating processors are <a href="#include-if-valid"><cite>not
|
|
obligated to</cite></a> to read and process entity declarations occurring in parameter entities or in
|
|
the external subset</span>; for such documents,
|
|
the rule that an entity must be declared is a well-formedness constraint only
|
|
if <a href="#sec-rmd"><cite>standalone='yes'</cite></a>.</p></div><div class="constraint"><p class="prefix"><a name="vc-entdeclared" id="vc-entdeclared" /><b>Validity constraint: Entity Declared</b></p><p>In a document with
|
|
an external subset or external parameter entities with "<code>standalone='no'</code>",
|
|
the <a href="#NT-Name">Name</a> given in the entity reference <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> <a title="match" href="#dt-match">match</a> that in an <a href="#sec-entity-decl"><cite>entity
|
|
declaration</cite></a>. For interoperability, valid documents <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> declare
|
|
the entities <code>amp</code>,
|
|
<code>lt</code>,
|
|
<code>gt</code>,
|
|
<code>apos</code>,
|
|
<code>quot</code>, in the form specified in <a href="#sec-predefined-ent"><b>4.6 Predefined Entities</b></a>.
|
|
The declaration of a parameter entity <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> precede any reference to it. Similarly,
|
|
the declaration of a general entity <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> precede any attribute-list
|
|
declaration containing a default value with a direct or indirect reference
|
|
to that general entity.</p></div><div class="constraint"><p class="prefix"><a name="textent" id="textent" /><b>Well-formedness constraint: Parsed Entity</b></p><p>An entity reference <em class="rfc2119" title="Keyword in RFC 2119 context">MUST
|
|
NOT</em> contain the name of an <a title="Unparsed Entity" href="#dt-unparsed">unparsed entity</a>.
|
|
Unparsed entities may be referred to only in <a title="Attribute Value" href="#dt-attrval">attribute
|
|
values</a> declared to be of type <b>ENTITY</b> or <b>ENTITIES</b>.</p></div><div class="constraint"><p class="prefix"><a name="norecursion" id="norecursion" /><b>Well-formedness constraint: No Recursion</b></p><p>A parsed entity <em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em> contain a recursive reference to itself, either directly or indirectly.</p></div><div class="constraint"><p class="prefix"><a name="indtd" id="indtd" /><b>Well-formedness constraint: In DTD</b></p><p>Parameter-entity references <span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em> appear outside</span>
|
|
the <a title="Document Type Declaration" href="#dt-doctype">DTD</a>.</p></div><p>Examples of character and entity references:</p><div class="exampleInner"><pre>Type <key>less-than</key> (&#x3C;) to save options.
|
|
This document was prepared on &docdate; and
|
|
is classified &security-level;.</pre></div><p>Example of a parameter-entity reference:</p><div class="exampleInner"><pre><!-- declare the parameter entity "ISOLat2"... -->
|
|
<!ENTITY % ISOLat2
|
|
SYSTEM "http://www.xml.com/iso/isolat2-xml.entities" >
|
|
<!-- ... now reference it. -->
|
|
%ISOLat2;</pre></div></div><div class="div2"> <h3><a name="sec-entity-decl" id="sec-entity-decl" />4.2 Entity Declarations</h3><p>[<a name="dt-entdecl" id="dt-entdecl" title="entity declaration">Definition</a>: Entities are declared
|
|
thus:]</p> <h5><a name="IDAECEU" id="IDAECEU" />Entity Declaration</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-EntityDecl" id="NT-EntityDecl" />[70] </td><td><code>EntityDecl</code></td><td> ::= </td><td><code><a href="#NT-GEDecl">GEDecl</a> | <a href="#NT-PEDecl">PEDecl</a></code></td></tr><tr valign="baseline"><td><a name="NT-GEDecl" id="NT-GEDecl" />[71] </td><td><code>GEDecl</code></td><td> ::= </td><td><code>'<!ENTITY' <a href="#NT-S">S</a> <a href="#NT-Name">Name</a> <a href="#NT-S">S</a> <a href="#NT-EntityDef">EntityDef</a> <a href="#NT-S">S</a>?
|
|
'>'</code></td></tr><tr valign="baseline"><td><a name="NT-PEDecl" id="NT-PEDecl" />[72] </td><td><code>PEDecl</code></td><td> ::= </td><td><code>'<!ENTITY' <a href="#NT-S">S</a> '%' <a href="#NT-S">S</a> <a href="#NT-Name">Name</a> <a href="#NT-S">S</a> <a href="#NT-PEDef">PEDef</a> <a href="#NT-S">S</a>? '>'</code></td></tr><tr valign="baseline"><td><a name="NT-EntityDef" id="NT-EntityDef" />[73] </td><td><code>EntityDef</code></td><td> ::= </td><td><code><a href="#NT-EntityValue">EntityValue</a>| (<a href="#NT-ExternalID">ExternalID</a> <a href="#NT-NDataDecl">NDataDecl</a>?)</code></td></tr><tr valign="baseline"><td><a name="NT-PEDef" id="NT-PEDef" />[74] </td><td><code>PEDef</code></td><td> ::= </td><td><code><a href="#NT-EntityValue">EntityValue</a> | <a href="#NT-ExternalID">ExternalID</a></code></td></tr></tbody></table><p>The <a href="#NT-Name">Name</a> identifies the entity in an <a title="Entity Reference" href="#dt-entref">entity
|
|
reference</a> or, in the case of an unparsed entity, in the value of
|
|
an <b>ENTITY</b> or <b>ENTITIES</b> attribute. If the same entity is declared
|
|
more than once, the first declaration encountered is binding; at user option,
|
|
an XML processor <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> issue a warning if entities are declared multiple times.</p><div class="div3"> <h4><a name="sec-internal-ent" id="sec-internal-ent" />4.2.1 Internal Entities</h4><p>[<a name="dt-internent" id="dt-internent" title="Internal Entity Replacement Text">Definition</a>: If the
|
|
entity definition is an <a href="#NT-EntityValue">EntityValue</a>, the defined
|
|
entity is called an <b>internal entity</b>. There is no separate physical
|
|
storage object, and the content of the entity is given in the declaration.]
|
|
Note that some processing of entity and character references in the <a title="Literal Entity Value" href="#dt-litentval">literal entity value</a> may be required to produce
|
|
the correct <a title="Replacement Text" href="#dt-repltext">replacement text</a>: see <a href="#intern-replacement"><b>4.5 Construction of Entity Replacement Text</b></a>.</p><p>An internal entity is a <a title="Text Entity" href="#dt-parsedent">parsed entity</a>.</p><p>Example of an internal entity declaration:</p><div class="exampleInner"><pre><!ENTITY Pub-Status "This is a pre-release of the
|
|
specification."></pre></div></div><div class="div3"> <h4><a name="sec-external-ent" id="sec-external-ent" />4.2.2 External Entities</h4><p>[<a name="dt-extent" id="dt-extent" title="External Entity">Definition</a>: If the entity is not internal,
|
|
it is an <b>external entity</b>, declared as follows:]</p> <h5><a name="IDAUIEU" id="IDAUIEU" />External Entity Declaration</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-ExternalID" id="NT-ExternalID" />[75] </td><td><code>ExternalID</code></td><td> ::= </td><td><code>'SYSTEM' <a href="#NT-S">S</a> <a href="#NT-SystemLiteral">SystemLiteral</a></code></td></tr><tr valign="baseline"><td /><td /><td /><td><code>| 'PUBLIC' <a href="#NT-S">S</a> <a href="#NT-PubidLiteral">PubidLiteral</a> <a href="#NT-S">S</a> <a href="#NT-SystemLiteral">SystemLiteral</a></code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-NDataDecl" id="NT-NDataDecl" />[76] </td><td><code>NDataDecl</code></td><td> ::= </td><td><code><a href="#NT-S">S</a> 'NDATA' <a href="#NT-S">S</a> <a href="#NT-Name">Name</a></code></td><td><a href="#not-declared">[VC: Notation Declared]</a></td></tr></tbody></table><p>If the <a href="#NT-NDataDecl">NDataDecl</a> is present, this is a general <a title="Unparsed Entity" href="#dt-unparsed">unparsed entity</a>; otherwise it is a parsed entity.</p><div class="constraint"><p class="prefix"><a name="not-declared" id="not-declared" /><b>Validity constraint: Notation Declared</b></p><p>The <a href="#NT-Name">Name</a> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> match the declared name of a <a title="Notation" href="#dt-notation">notation</a>.</p></div><p>[<a name="dt-sysid" id="dt-sysid" title="System Identifier">Definition</a>: The <a href="#NT-SystemLiteral">SystemLiteral</a> is called the entity's <b>system
|
|
identifier</b>. It is <span>meant to be
|
|
converted to</span> a URI reference
|
|
(as defined in <a href="#rfc2396">[IETF RFC 2396]</a>, updated by <a href="#rfc2732">[IETF RFC 2732]</a>),
|
|
<span>as part of the
|
|
process of dereferencing it</span> to obtain input for the XML processor to construct the
|
|
entity's replacement text.] It is an error for a fragment identifier
|
|
(beginning with a <code>#</code> character) to be part of a system identifier.
|
|
Unless otherwise provided by information outside the scope of this specification
|
|
(e.g. a special XML element type defined by a particular DTD, or a processing
|
|
instruction defined by a particular application specification), relative URIs
|
|
are relative to the location of the resource within which the entity declaration
|
|
occurs. <span>This is defined to
|
|
be the external entity containing the '<' which starts the declaration, at the
|
|
point when it is parsed as a declaration.</span>
|
|
A URI might thus be relative to the <a title="Document Entity" href="#dt-docent">document
|
|
entity</a>, to the entity containing the <a title="Document Type Declaration" href="#dt-doctype">external
|
|
DTD subset</a>, or to some other <a title="External Entity" href="#dt-extent">external parameter
|
|
entity</a>. <span>Attempts to
|
|
retrieve the resource identified by a URI <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> be redirected at the parser
|
|
level (for example, in an entity resolver) or below (at the protocol level,
|
|
for example, via an HTTP <code>Location:</code> header). In the absence of additional
|
|
information outside the scope of this specification within the resource,
|
|
the base URI of a resource is always the URI of the actual resource returned.
|
|
In other words, it is the URI of the resource retrieved after all redirection
|
|
has occurred.</span></p><p>System
|
|
identifiers (and other XML strings meant to be used as URI references) <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> contain
|
|
characters that, according to <a href="#rfc2396">[IETF RFC 2396]</a> and <a href="#rfc2732">[IETF RFC 2732]</a>,
|
|
must be escaped before a URI can be used to retrieve the referenced resource. The
|
|
characters to be escaped are the control characters #x0 to #x1F and #x7F (most of
|
|
which cannot appear in XML), space #x20, the delimiters '<' #x3C, '>' #x3E and
|
|
'"' #x22, the <em>unwise</em> characters '{' #x7B, '}' #x7D, '|' #x7C, '\' #x5C, '^' #x5E and
|
|
'`' #x60, as well as all characters above #x7F. Since escaping is not always a fully
|
|
reversible process, it <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be performed only when absolutely necessary and as late
|
|
as possible in a processing chain. In particular, neither the process of converting
|
|
a relative URI to an absolute one nor the process of passing a URI reference to a
|
|
process or software component responsible for dereferencing it <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> trigger escaping.
|
|
When escaping does occur, it <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be performed as follows:</p><ol type="1"><li><p>Each
|
|
character <span>to be escaped</span>
|
|
is <span>represented in</span>
|
|
UTF-8 <span><a href="#Unicode">[Unicode]</a></span>
|
|
as one or more bytes.</p></li><li><p><span>The resulting bytes</span>
|
|
are escaped with
|
|
the URI escaping mechanism (that is, converted to <code>%</code><var>HH</var>,
|
|
where HH is the hexadecimal notation of the byte value).</p></li><li><p>The original character is replaced by the resulting character sequence.</p></li></ol><p>[<a name="dt-pubid" id="dt-pubid" title="Public identifier">Definition</a>: In addition to a system
|
|
identifier, an external identifier <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> include a <b>public identifier</b>.]
|
|
An XML processor attempting to retrieve the entity's content <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> use
|
|
<span>any combination of
|
|
the public and system identifiers as well as additional information outside the
|
|
scope of this specification</span> to try to generate an alternative URI reference.
|
|
If the processor is unable to do so, it <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> use the URI
|
|
reference specified in the system literal. Before a match is attempted,
|
|
all strings of white space in the public identifier <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be normalized to
|
|
single space characters (#x20), and leading and trailing white space <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em>
|
|
be removed.</p><p>Examples of external entity declarations:</p><div class="exampleInner"><pre><!ENTITY open-hatch
|
|
SYSTEM "http://www.textuality.com/boilerplate/OpenHatch.xml">
|
|
<!ENTITY open-hatch
|
|
PUBLIC "-//Textuality//TEXT Standard open-hatch boilerplate//EN"
|
|
"http://www.textuality.com/boilerplate/OpenHatch.xml">
|
|
<!ENTITY hatch-pic
|
|
SYSTEM "../grafix/OpenHatch.gif"
|
|
NDATA gif ></pre></div></div></div><div class="div2"> <h3><a name="TextEntities" id="TextEntities" />4.3 Parsed Entities</h3><div class="div3"> <h4><a name="sec-TextDecl" id="sec-TextDecl" />4.3.1 The Text Declaration</h4><p>External parsed entities <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> each begin with a <b>text declaration</b>.</p> <h5><a name="IDAUPEU" id="IDAUPEU" />Text Declaration</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-TextDecl" id="NT-TextDecl" />[77] </td><td><code>TextDecl</code></td><td> ::= </td><td><code>'<?xml' <a href="#NT-VersionInfo">VersionInfo</a>? <a href="#NT-EncodingDecl">EncodingDecl</a> <a href="#NT-S">S</a>? '?>'</code></td></tr></tbody></table><p>The text declaration <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be provided literally, not by reference
|
|
to a parsed entity. <span class="mustard">The</span> text declaration
|
|
<span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em></span> appear at any
|
|
position other than the beginning of an external parsed entity. The text declaration
|
|
in an external parsed entity is not considered part of its <a title="Replacement Text" href="#dt-repltext">replacement text</a>.</p></div><div class="div3"> <h4><a name="wf-entities" id="wf-entities" />4.3.2 Well-Formed Parsed Entities</h4><p>The document entity is well-formed if it matches the production labeled <a href="#NT-document">document</a>. An external general parsed entity is well-formed
|
|
if it matches the production labeled <a href="#NT-extParsedEnt">extParsedEnt</a>. All
|
|
external parameter entities are well-formed by definition.</p> <h5><a name="IDA2REU" id="IDA2REU" />Well-Formed External Parsed Entity</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-extParsedEnt" id="NT-extParsedEnt" />[78] </td><td><code>extParsedEnt</code></td><td> ::= </td><td><code><a href="#NT-TextDecl">TextDecl</a>? <a href="#NT-content">content</a> - <a href="#NT-Char">Char</a>* <a href="#NT-RestrictedChar">RestrictedChar</a> <a href="#NT-Char">Char</a>*</code></td></tr></tbody></table><p>An internal general parsed entity is well-formed if its replacement text
|
|
matches the production labeled <a href="#NT-content">content</a>. All internal
|
|
parameter entities are well-formed by definition.</p><p>A consequence of well-formedness in <span>general</span>
|
|
entities is that the logical and physical
|
|
structures in an XML document are properly nested; no <a title="Start-Tag" href="#dt-stag">start-tag</a>, <a title="End Tag" href="#dt-etag">end-tag</a>, <a title="Empty" href="#dt-empty">empty-element tag</a>, <a title="Element" href="#dt-element">element</a>, <a title="Comment" href="#dt-comment">comment</a>, <a title="Processing instruction" href="#dt-pi">processing instruction</a>, <a title="Character Reference" href="#dt-charref">character
|
|
reference</a>, or <a title="Entity Reference" href="#dt-entref">entity reference</a>
|
|
can begin in one entity and end in another.</p></div><div class="div3"> <h4><a name="charencoding" id="charencoding" />4.3.3 Character Encoding in Entities</h4><p>Each external parsed entity in an XML document <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> use a different encoding
|
|
for its characters. All XML processors <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be able to read entities in both
|
|
the UTF-8 and UTF-16 encodings. The terms "UTF-8"
|
|
and "UTF-16" in this specification do not apply to character
|
|
encodings with any other labels, even if the encodings or labels are very
|
|
similar to UTF-8 or UTF-16.</p><p>Entities encoded in UTF-16 <span><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em></span> <span>and entities
|
|
encoded in UTF-8 <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em></span> begin with the Byte Order Mark described in
|
|
ISO/IEC 10646 <a href="#ISO10646">[ISO/IEC 10646]</a> or Unicode <a href="#Unicode">[Unicode]</a>
|
|
(the ZERO WIDTH NO-BREAK SPACE character, #xFEFF). This is an encoding signature,
|
|
not part of either the markup or the character data of the XML document. XML
|
|
processors <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be able to use this character to differentiate between UTF-8
|
|
and UTF-16 encoded documents.</p><p>Although an XML processor is required to read only entities in the UTF-8
|
|
and UTF-16 encodings, it is recognized that other encodings are used around
|
|
the world, and it may be desired for XML processors to read entities that
|
|
use them. In
|
|
the absence of external character encoding information (such as MIME headers),
|
|
parsed entities which are stored in an encoding other than UTF-8 or UTF-16
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> begin with a text declaration (see <a href="#sec-TextDecl"><b>4.3.1 The Text Declaration</b></a>) containing
|
|
an encoding declaration:</p> <h5><a name="IDARVEU" id="IDARVEU" />Encoding Declaration</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-EncodingDecl" id="NT-EncodingDecl" />[80] </td><td><code>EncodingDecl</code></td><td> ::= </td><td><code><a href="#NT-S">S</a> 'encoding' <a href="#NT-Eq">Eq</a>
|
|
('"' <a href="#NT-EncName">EncName</a> '"' | "'" <a href="#NT-EncName">EncName</a>
|
|
"'" ) </code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-EncName" id="NT-EncName" />[81] </td><td><code>EncName</code></td><td> ::= </td><td><code>[A-Za-z] ([A-Za-z0-9._] | '-')*</code></td><td><i>/* Encoding
|
|
name contains only Latin characters */</i></td></tr></tbody></table><p>In the <a title="Document Entity" href="#dt-docent">document entity</a>, the encoding
|
|
declaration is part of the <a title="XML Declaration" href="#dt-xmldecl">XML declaration</a>.
|
|
The <a href="#NT-EncName">EncName</a> is the name of the encoding used.</p><p>In an encoding declaration, the values "<code>UTF-8</code>", "<code>UTF-16</code>",
|
|
"<code>ISO-10646-UCS-2</code>", and "<code>ISO-10646-UCS-4</code>" <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> be used
|
|
for the various encodings and transformations of Unicode / ISO/IEC 10646,
|
|
the values "<code>ISO-8859-1</code>", "<code>ISO-8859-2</code>",
|
|
... "<code>ISO-8859-</code><var>n</var>" (where <var>n</var>
|
|
is the part number) <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> be used for the parts of ISO 8859, and
|
|
the values "<code>ISO-2022-JP</code>", "<code>Shift_JIS</code>",
|
|
and "<code>EUC-JP</code>" <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> be used for the various encoded
|
|
forms of JIS X-0208-1997. It
|
|
is <em class="rfc2119" title="Keyword in RFC 2119 context">RECOMMENDED</em> that character encodings registered (as <em>charset</em>s)
|
|
with the Internet Assigned Numbers Authority <a href="#IANA">[IANA-CHARSETS]</a>,
|
|
other than those just listed, be referred to using their registered names;
|
|
other encodings <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> use names starting with an "x-" prefix.
|
|
XML processors <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> match character encoding names in a case-insensitive
|
|
way and <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> either interpret an IANA-registered name as the encoding registered
|
|
at IANA for that name or treat it as unknown (processors are, of course, not
|
|
required to support all IANA-registered encodings).</p><p>In the absence of information provided by an external transport protocol
|
|
(e.g. HTTP or MIME), it is a <a title="Fatal Error" href="#dt-fatal">fatal error</a> for
|
|
an entity including an encoding declaration to be presented to the XML processor
|
|
in an encoding other than that named in the declaration, or for an entity which
|
|
begins with neither a Byte Order Mark
|
|
nor an encoding declaration to use an encoding other than UTF-8. Note that
|
|
since ASCII is a subset of UTF-8, ordinary ASCII entities do not strictly
|
|
need an encoding declaration.</p><p>It is a <a title="Fatal Error" href="#dt-fatal">fatal error</a> for a <a href="#NT-TextDecl">TextDecl</a> to occur other
|
|
than at the beginning of an external entity.</p><p>It is a <a title="Fatal Error" href="#dt-fatal">fatal error</a> when an XML processor
|
|
encounters an entity with an encoding that it is unable to process. It
|
|
is a <a title="Fatal Error" href="#dt-fatal">fatal error</a> if an XML entity is determined (via default, encoding declaration,
|
|
or higher-level protocol) to be in a certain encoding but contains <span>byte</span>
|
|
sequences that are not legal in that encoding. <span>Specifically, it is a
|
|
fatal error if an entity encoded in UTF-8 contains any irregular code unit sequences,
|
|
as defined in Unicode <a href="#Unicode">[Unicode]</a>.</span> <span>Unless an encoding
|
|
is determined by a higher-level protocol, </span>it is also a <a title="Fatal Error" href="#dt-fatal">fatal error</a> if an XML entity
|
|
contains no encoding declaration and its content is not legal UTF-8 or UTF-16.</p><p>Examples of text declarations containing encoding declarations:</p><div class="exampleInner"><pre><?xml encoding='UTF-8'?>
|
|
<?xml encoding='EUC-JP'?></pre></div></div><div class="div3"> <h4><a name="sec-version-info" id="sec-version-info" />4.3.4 Version Information in Entities</h4><p>Each entity, including the <a title="Document Entity" href="#dt-docent">document entity</a>,
|
|
can be separately
|
|
declared as XML 1.0 or XML 1.1. The version declaration appearing
|
|
in the document entity determines the version of the document as a
|
|
whole. An XML 1.1 document may invoke XML 1.0 external entities, so
|
|
that otherwise duplicated versions of external entities,
|
|
particularly DTD external subsets, need not be maintained. However,
|
|
in such a case the rules of XML 1.1 are applied to the entire
|
|
document.</p><p> If an entity (including the document entity) is not labeled
|
|
with a version number, it is treated as if labeled as version
|
|
1.0.</p></div></div><div class="div2"> <h3><a name="entproc" id="entproc" />4.4 XML Processor Treatment of Entities and References</h3><p>The table below summarizes the contexts in which character references,
|
|
entity references, and invocations of unparsed entities might appear and the
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">REQUIRED</em> behavior of an <a title="XML Processor" href="#dt-xml-proc">XML processor</a>
|
|
in each case. The labels in the leftmost column describe the recognition context: </p><dl><dt class="label">Reference in Content</dt><dd><p>as a reference anywhere after the <a title="Start-Tag" href="#dt-stag">start-tag</a>
|
|
and before the <a title="End Tag" href="#dt-etag">end-tag</a> of an element; corresponds
|
|
to the nonterminal <a href="#NT-content">content</a>.</p></dd><dt class="label">Reference in Attribute Value</dt><dd><p>as a reference within either the value of an attribute in a <a title="Start-Tag" href="#dt-stag">start-tag</a>,
|
|
or a default value in an <a title="Attribute-List Declaration" href="#dt-attdecl">attribute declaration</a>;
|
|
corresponds to the nonterminal <a href="#NT-AttValue">AttValue</a>.</p></dd><dt class="label">Occurs as Attribute Value</dt><dd><p>as a <a href="#NT-Name">Name</a>, not a reference, appearing either as
|
|
the value of an attribute which has been declared as type <b>ENTITY</b>,
|
|
or as one of the space-separated tokens in the value of an attribute which
|
|
has been declared as type <b>ENTITIES</b>.</p></dd><dt class="label">Reference in Entity Value</dt><dd><p>as a reference within a parameter or internal entity's <a title="Literal Entity Value" href="#dt-litentval">literal
|
|
entity value</a> in the entity's declaration; corresponds to the nonterminal <a href="#NT-EntityValue">EntityValue</a>.</p></dd><dt class="label">Reference in DTD</dt><dd><p>as a reference within either the internal or external subsets of the <a title="Document Type Declaration" href="#dt-doctype">DTD</a>, but outside of an <a href="#NT-EntityValue">EntityValue</a>, <a href="#NT-AttValue">AttValue</a>, <a href="#NT-PI">PI</a>, <a href="#NT-Comment">Comment</a>, <a href="#NT-SystemLiteral">SystemLiteral</a>, <a href="#NT-PubidLiteral">PubidLiteral</a>,
|
|
or the contents of an ignored conditional section (see <a href="#sec-condition-sect"><b>3.4 Conditional Sections</b></a>).</p><p>.</p></dd></dl><p></p><table border="1" frame="border" cellpadding="7" summary="Entity type/reference matrix"><tbody align="center"><tr><td rowspan="2" colspan="1"></td><td colspan="4" align="center" valign="bottom" rowspan="1">Entity
|
|
Type</td><td rowspan="2" align="center" colspan="1">Character</td></tr><tr align="center" valign="bottom"><td rowspan="1" colspan="1">Parameter</td><td rowspan="1" colspan="1">Internal General</td><td rowspan="1" colspan="1">External Parsed
|
|
General</td><td rowspan="1" colspan="1">Unparsed</td></tr><tr align="center" valign="middle"><td align="right" rowspan="1" colspan="1">Reference
|
|
in Content</td><td rowspan="1" colspan="1"><a href="#not-recognized"><cite>Not recognized</cite></a></td><td rowspan="1" colspan="1"><a href="#included"><cite>Included</cite></a></td><td rowspan="1" colspan="1"><a href="#include-if-valid"><cite>Included
|
|
if validating</cite></a></td><td rowspan="1" colspan="1"><a href="#forbidden"><cite>Forbidden</cite></a></td><td rowspan="1" colspan="1"><a href="#included"><cite>Included</cite></a></td></tr><tr align="center" valign="middle"><td align="right" rowspan="1" colspan="1">Reference in Attribute Value</td><td rowspan="1" colspan="1"><a href="#not-recognized"><cite>Not recognized</cite></a></td><td rowspan="1" colspan="1"><a href="#inliteral"><cite>Included
|
|
in literal</cite></a></td><td rowspan="1" colspan="1"><a href="#forbidden"><cite>Forbidden</cite></a></td><td rowspan="1" colspan="1"><a href="#forbidden"><cite>Forbidden</cite></a></td><td rowspan="1" colspan="1"><a href="#included"><cite>Included</cite></a></td></tr><tr align="center" valign="middle"><td align="right" rowspan="1" colspan="1">Occurs as Attribute
|
|
Value</td><td rowspan="1" colspan="1"><a href="#not-recognized"><cite>Not recognized</cite></a></td><td rowspan="1" colspan="1"><a href="#forbidden"><cite>Forbidden</cite></a></td><td rowspan="1" colspan="1"><a href="#forbidden"><cite>Forbidden</cite></a></td><td rowspan="1" colspan="1"><a href="#notify"><cite>Notify</cite></a></td><td rowspan="1" colspan="1"><a href="#not-recognized"><cite>Not recognized</cite></a></td></tr><tr align="center" valign="middle"><td align="right" rowspan="1" colspan="1">Reference in EntityValue</td><td rowspan="1" colspan="1"><a href="#inliteral"><cite>Included in literal</cite></a></td><td rowspan="1" colspan="1"><a href="#bypass"><cite>Bypassed</cite></a></td><td rowspan="1" colspan="1"><a href="#bypass"><cite>Bypassed</cite></a></td><td rowspan="1" colspan="1"><a href="#error"><cite><span>Error</span></cite></a></td><td rowspan="1" colspan="1"><a href="#included"><cite>Included</cite></a></td></tr><tr align="center" valign="middle"><td align="right" rowspan="1" colspan="1">Reference in DTD</td><td rowspan="1" colspan="1"><a href="#as-PE"><cite>Included as PE</cite></a></td><td rowspan="1" colspan="1"><a href="#forbidden"><cite>Forbidden</cite></a></td><td rowspan="1" colspan="1"><a href="#forbidden"><cite>Forbidden</cite></a></td><td rowspan="1" colspan="1"><a href="#forbidden"><cite>Forbidden</cite></a></td><td rowspan="1" colspan="1"><a href="#forbidden"><cite>Forbidden</cite></a></td></tr></tbody></table><div class="div3"> <h4><a name="not-recognized" id="not-recognized" />4.4.1 Not Recognized</h4><p>Outside the DTD, the <code>%</code> character has no special significance;
|
|
thus, what would be parameter entity references in the DTD are not recognized
|
|
as markup in <a href="#NT-content">content</a>. Similarly, the names of unparsed
|
|
entities are not recognized except when they appear in the value of an appropriately
|
|
declared attribute.</p></div><div class="div3"> <h4><a name="included" id="included" />4.4.2 Included</h4><p>[<a name="dt-include" id="dt-include" title="Include">Definition</a>: An entity is <b>included</b>
|
|
when its <a title="Replacement Text" href="#dt-repltext">replacement text</a> is retrieved
|
|
and processed, in place of the reference itself, as though it were part of
|
|
the document at the location the reference was recognized.] The replacement
|
|
text <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> contain both <a title="Character Data" href="#dt-chardata">character data</a>
|
|
and (except for parameter entities) <a title="Markup" href="#dt-markup">markup</a>,
|
|
which <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be recognized in the usual way. (The string "<code>AT&amp;T;</code>"
|
|
expands to "<code>AT&T;</code>" and the remaining ampersand
|
|
is not recognized as an entity-reference delimiter.) A character reference
|
|
is <b>included</b> when the indicated character is processed in place
|
|
of the reference itself. </p></div><div class="div3"> <h4><a name="include-if-valid" id="include-if-valid" />4.4.3 Included If Validating</h4><p>When an XML processor recognizes a reference to a parsed entity, in order
|
|
to <a title="Validity" href="#dt-valid">validate</a> the document, the processor
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> <a title="Include" href="#dt-include">include</a> its replacement text. If
|
|
the entity is external, and the processor is not attempting to validate the
|
|
XML document, the processor <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em>, but need
|
|
not, include the entity's replacement text. If a non-validating processor
|
|
does not include the replacement text, it <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> inform the application that
|
|
it recognized, but did not read, the entity.</p><p>This rule is based on the recognition that the automatic inclusion provided
|
|
by the SGML and XML entity mechanism, primarily designed to support modularity
|
|
in authoring, is not necessarily appropriate for other applications, in particular
|
|
document browsing. Browsers, for example, when encountering an external parsed
|
|
entity reference, might choose to provide a visual indication of the entity's
|
|
presence and retrieve it for display only on demand.</p></div><div class="div3"> <h4><a name="forbidden" id="forbidden" />4.4.4 Forbidden</h4><p>The following are forbidden, and constitute <a title="Fatal Error" href="#dt-fatal">fatal
|
|
errors</a>:</p><ul><li><p>the appearance of a reference to an <a title="Unparsed Entity" href="#dt-unparsed">unparsed
|
|
entity</a><span>, except in the
|
|
<a href="#NT-EntityValue">EntityValue</a> in an entity declaration</span>.</p></li><li><p>the appearance of any character or general-entity reference in the
|
|
DTD except within an <a href="#NT-EntityValue">EntityValue</a> or <a href="#NT-AttValue">AttValue</a>.</p></li><li><p>a reference to an external entity in an attribute value.</p></li></ul></div><div class="div3"> <h4><a name="inliteral" id="inliteral" />4.4.5 Included in Literal</h4><p>When an <a title="Entity Reference" href="#dt-entref">entity reference</a> appears in
|
|
an attribute value, or a parameter entity reference appears in a literal entity
|
|
value, its <a title="Replacement Text" href="#dt-repltext">replacement text</a> <span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be</span> processed
|
|
in place of the reference itself as though it were part of the document at
|
|
the location the reference was recognized, except that a single or double
|
|
quote character in the replacement text <span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> always be</span> treated as a normal data
|
|
character and <span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em></span> terminate the literal. For example, this is well-formed:</p><div class="exampleInner"><pre><!ENTITY % YN '"Yes"' >
|
|
<!ENTITY WhatHeSaid "He said %YN;" ></pre></div><p>while this is not:</p><div class="exampleInner"><pre><!ENTITY EndAttr "27'" >
|
|
<element attribute='a-&EndAttr;></pre></div></div><div class="div3"> <h4><a name="notify" id="notify" />4.4.6 Notify</h4><p>When the name of an <a title="Unparsed Entity" href="#dt-unparsed">unparsed entity</a>
|
|
appears as a token in the value of an attribute of declared type <b>ENTITY</b>
|
|
or <b>ENTITIES</b>, a validating processor <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> inform the application of
|
|
the <a title="System Identifier" href="#dt-sysid">system</a> and <a title="Public identifier" href="#dt-pubid">public</a>
|
|
(if any) identifiers for both the entity and its associated <a title="Notation" href="#dt-notation">notation</a>.</p></div><div class="div3"> <h4><a name="bypass" id="bypass" />4.4.7 Bypassed</h4><p>When a general entity reference appears in the <a href="#NT-EntityValue">EntityValue</a>
|
|
in an entity declaration, it <span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be</span> bypassed and left as is.</p></div><div class="div3"> <h4><a name="as-PE" id="as-PE" />4.4.8 Included as PE</h4><p>Just as with external parsed entities, parameter entities need only be <a href="#include-if-valid"><cite>included if validating</cite></a>. When a parameter-entity
|
|
reference is recognized in the DTD and included, its <a title="Replacement Text" href="#dt-repltext">replacement
|
|
text</a> <span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be</span> enlarged by the attachment of one leading and one following
|
|
space (#x20) character; the intent is to constrain the replacement text of
|
|
parameter entities to contain an integral number of grammatical tokens in
|
|
the DTD. This
|
|
behavior <span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em></span> apply to parameter entity references within entity values;
|
|
these are described in <a href="#inliteral"><b>4.4.5 Included in Literal</b></a>.</p></div><div class="div3"> <h4><a name="error" id="error" />4.4.9 Error</h4><p>It is an <a title="Error" href="#dt-error">error</a> for a reference to
|
|
an unparsed entity to appear in the <a href="#NT-EntityValue">EntityValue</a> in an
|
|
entity declaration.</p></div></div><div class="div2"> <h3><a name="intern-replacement" id="intern-replacement" />4.5 Construction of Entity Replacement Text</h3><p>In discussing the treatment of entities, it is useful to distinguish
|
|
two forms of the entity's value.
|
|
[<a name="dt-litentval" id="dt-litentval" title="Literal Entity Value">Definition</a>: <span>For an
|
|
internal entity, </span>the <b>literal
|
|
entity value</b> is the quoted string actually present in the entity declaration,
|
|
corresponding to the non-terminal <a href="#NT-EntityValue">EntityValue</a>.] [<a name="dt-extlitentval" id="dt-extlitentval" title="Literal Entity Value">Definition</a>: For an external entity, the <b>literal
|
|
entity value</b> is the exact text contained in the entity.] [<a name="dt-repltext" id="dt-repltext" title="Replacement Text">Definition</a>: <span>For an
|
|
internal entity, </span>the <b>replacement text</b>
|
|
is the content of the entity, after replacement of character references and
|
|
parameter-entity references.] [<a name="dt-extrepltext" id="dt-extrepltext" title="Replacement Text">Definition</a>: For
|
|
an external entity, the <b>replacement text</b> is the content of the entity,
|
|
after stripping the text declaration (leaving any surrounding white space) if there
|
|
is one but without any replacement of character references or parameter-entity
|
|
references.]</p><p>The literal entity value as given in an internal entity declaration (<a href="#NT-EntityValue">EntityValue</a>) <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> contain character, parameter-entity,
|
|
and general-entity references. Such references <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be contained entirely
|
|
within the literal entity value. The actual replacement text that is <a title="Include" href="#dt-include">included</a><span> (or <a title="" href="#inliteral">included in literal</a>)</span> as described above
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> contain the <em>replacement
|
|
text</em> of any parameter entities referred to, and <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> contain the character
|
|
referred to, in place of any character references in the literal entity value;
|
|
however, general-entity references <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be left as-is, unexpanded. For example,
|
|
given the following declarations:</p><div class="exampleInner"><pre><!ENTITY % pub "&#xc9;ditions Gallimard" >
|
|
<!ENTITY rights "All rights reserved" >
|
|
<!ENTITY book "La Peste: Albert Camus,
|
|
&#xA9; 1947 %pub;. &rights;" ></pre></div><p>then the replacement text for the entity "<code>book</code>"
|
|
is:</p><div class="exampleInner"><pre>La Peste: Albert Camus,
|
|
© 1947 Éditions Gallimard. &rights;</pre></div><p>The general-entity reference "<code>&rights;</code>" would
|
|
be expanded should the reference "<code>&book;</code>" appear
|
|
in the document's content or an attribute value.</p><p>These simple rules may have complex interactions; for a detailed discussion
|
|
of a difficult example, see <a href="#sec-entexpand"><b>C Expansion of Entity and Character References</b></a>.</p></div><div class="div2"> <h3><a name="sec-predefined-ent" id="sec-predefined-ent" />4.6 Predefined Entities</h3><p>[<a name="dt-escape" id="dt-escape" title="escape">Definition</a>: Entity and character references <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em>
|
|
both be used to <b>escape</b> the left angle bracket, ampersand, and
|
|
other delimiters. A set of general entities (<code>amp</code>,
|
|
<code>lt</code>,
|
|
<code>gt</code>,
|
|
<code>apos</code>,
|
|
<code>quot</code>) is specified for
|
|
this purpose. Numeric character references <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> also be used; they are expanded
|
|
immediately when recognized and <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be treated as character data, so the
|
|
numeric character references "<code>&#60;</code>" and "<code>&#38;</code>" <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> be used to escape <code><</code> and <code>&</code> when they occur
|
|
in character data.]</p><p>All XML processors <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> recognize these entities whether they are declared
|
|
or not. <a title="For interoperability" href="#dt-interop">For interoperability</a>, valid XML
|
|
documents <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> declare these entities, like any others, before using them. If
|
|
the entities <code>lt</code> or <code>amp</code> are declared, they <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be
|
|
declared as internal entities whose replacement text is a character reference
|
|
to the respective
|
|
character (less-than sign or ampersand) being escaped; the double
|
|
escaping is <em class="rfc2119" title="Keyword in RFC 2119 context">REQUIRED</em> for these entities so that references to them produce
|
|
a well-formed result. If the entities <code>gt</code>, <code>apos</code>,
|
|
or <code>quot</code> are declared, they <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be declared as internal entities
|
|
whose replacement text is the single character being escaped (or a character
|
|
reference to that character; the double escaping here is <span class="mustard"><em class="rfc2119" title="Keyword in RFC 2119 context">OPTIONAL</em></span> but harmless).
|
|
For example:</p><div class="exampleInner"><pre><!ENTITY lt "&#38;#60;">
|
|
<!ENTITY gt "&#62;">
|
|
<!ENTITY amp "&#38;#38;">
|
|
<!ENTITY apos "&#39;">
|
|
<!ENTITY quot "&#34;"></pre></div></div><div class="div2"> <h3><a name="Notations" id="Notations" />4.7 Notation Declarations</h3><p>[<a name="dt-notation" id="dt-notation" title="Notation">Definition</a>: <b>Notations</b> identify
|
|
by name the format of <a title="External Entity" href="#dt-extent">unparsed entities</a>,
|
|
the format of elements which bear a notation attribute, or the application
|
|
to which a <a title="Processing instruction" href="#dt-pi">processing instruction</a> is addressed.]</p><p>[<a name="dt-notdecl" id="dt-notdecl" title="Notation Declaration">Definition</a>: <b>Notation declarations</b>
|
|
provide a name for the notation, for use in entity and attribute-list declarations
|
|
and in attribute specifications, and an external identifier for the notation
|
|
which may allow an XML processor or its client application to locate a helper
|
|
application capable of processing data in the given notation.]</p> <h5><a name="IDAYTFU" id="IDAYTFU" />Notation Declarations</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="NT-NotationDecl" id="NT-NotationDecl" />[82] </td><td><code>NotationDecl</code></td><td> ::= </td><td><code>'<!NOTATION' <a href="#NT-S">S</a> <a href="#NT-Name">Name</a> <a href="#NT-S">S</a> (<a href="#NT-ExternalID">ExternalID</a> | <a href="#NT-PublicID">PublicID</a>) <a href="#NT-S">S</a>? '>'</code></td><td><a href="#UniqueNotationName">[VC: Unique Notation Name]</a></td></tr></tbody><tbody><tr valign="baseline"><td><a name="NT-PublicID" id="NT-PublicID" />[83] </td><td><code>PublicID</code></td><td> ::= </td><td><code>'PUBLIC' <a href="#NT-S">S</a> <a href="#NT-PubidLiteral">PubidLiteral</a></code></td></tr></tbody></table><div class="constraint"><p class="prefix"><a name="UniqueNotationName" id="UniqueNotationName" /><b>Validity constraint: Unique Notation Name</b></p><p><span class="mustard">A given <a href="#NT-Name">Name</a> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em> be declared in more than one notation declaration.</span></p></div><p>XML processors <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> provide applications with the name and external identifier(s)
|
|
of any notation declared and referred to in an attribute value, attribute
|
|
definition, or entity declaration. They <em class="rfc2119" title="Keyword in RFC 2119 context">MAY</em> additionally resolve the external
|
|
identifier into the <a title="System Identifier" href="#dt-sysid">system identifier</a>, file
|
|
name, or other information needed to allow the application to call a processor
|
|
for data in the notation described. (It is not an error, however, for XML
|
|
documents to declare and refer to notations for which notation-specific applications
|
|
are not available on the system where the XML processor or application is
|
|
running.)</p></div><div class="div2"> <h3><a name="sec-doc-entity" id="sec-doc-entity" />4.8 Document Entity</h3><p>[<a name="dt-docent" id="dt-docent" title="Document Entity">Definition</a>: The <b>document entity</b>
|
|
serves as the root of the entity tree and a starting-point for an <a title="XML Processor" href="#dt-xml-proc">XML processor</a>.] This specification does
|
|
not specify how the document entity is to be located by an XML processor;
|
|
unlike other entities, the document entity has no name and might well appear
|
|
on a processor input stream without any identification at all.</p></div></div><div class="div1"> <h2><a name="sec-conformance" id="sec-conformance" />5 Conformance</h2><div class="div2"> <h3><a name="proc-types" id="proc-types" />5.1 Validating and Non-Validating Processors</h3><p>Conforming <a title="XML Processor" href="#dt-xml-proc">XML processors</a> fall into
|
|
two classes: validating and non-validating.</p><p>Validating and non-validating processors alike <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> report violations of
|
|
this specification's well-formedness constraints in the content of the <a title="Document Entity" href="#dt-docent">document entity</a> and any other <a title="Text Entity" href="#dt-parsedent">parsed
|
|
entities</a> that they read.</p><p>[<a name="dt-validating" id="dt-validating" title="Validating Processor">Definition</a>: <b>Validating
|
|
processors</b> <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em>,
|
|
at user option, report violations of the constraints expressed by
|
|
the declarations in the <a title="Document Type Declaration" href="#dt-doctype">DTD</a>, and failures
|
|
to fulfill the validity constraints given in this specification.]
|
|
To accomplish this, validating XML processors <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> read and process the entire
|
|
DTD and all external parsed entities referenced in the document.</p><p>Non-validating processors are <em class="rfc2119" title="Keyword in RFC 2119 context">REQUIRED</em> to check only the <a title="Document Entity" href="#dt-docent">document
|
|
entity</a>, including the entire internal DTD subset, for well-formedness. [<a name="dt-use-mdecl" id="dt-use-mdecl" title="Process Declarations">Definition</a>: While they are not required
|
|
to check the document for validity, they are <em class="rfc2119" title="Keyword in RFC 2119 context">REQUIRED</em> to <b>process</b>
|
|
all the declarations they read in the internal DTD subset and in any parameter
|
|
entity that they read, up to the first reference to a parameter entity that
|
|
they do <em>not</em> read; that is to say, they <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> use the information
|
|
in those declarations to <a href="#AVNormalize"><cite>normalize</cite></a>
|
|
attribute values, <a href="#included"><cite>include</cite></a> the replacement
|
|
text of internal entities, and supply <a href="#sec-attr-defaults"><cite>default
|
|
attribute values</cite></a>.] Except when <code>standalone="yes"</code>, they
|
|
<em class="rfc2119" title="Keyword in RFC 2119 context">MUST NOT</em> <a title="Process Declarations" href="#dt-use-mdecl">process</a> <a title="entity declaration" href="#dt-entdecl">entity
|
|
declarations</a> or <a title="Attribute-List Declaration" href="#dt-attdecl">attribute-list declarations</a>
|
|
encountered after a reference to a parameter entity that is not read, since
|
|
the entity may have contained overriding declarations<span>; when <code>standalone="yes"</code>, processors <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em>
|
|
process these declarations</span>.</p><p>Note
|
|
that when processing invalid documents with a non-validating
|
|
processor the application may not be presented with consistent
|
|
information. For example, several requirements for uniqueness
|
|
within the document may not be met, including more than one element
|
|
with the same id, duplicate declarations of elements or notations
|
|
with the same name, etc. In these cases the behavior of the parser
|
|
with respect to reporting such information to the application is
|
|
undefined.</p><p>XML 1.1 processors <em class="rfc2119" title="Keyword in RFC 2119 context">MUST</em> be able to process both XML 1.0
|
|
and XML 1.1 documents. Programs which generate XML <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em>
|
|
generate XML 1.0, unless one of the specific features of XML 1.1 is required.</p></div><div class="div2"> <h3><a name="safe-behavior" id="safe-behavior" />5.2 Using XML Processors</h3><p>The behavior of a validating XML processor is highly predictable; it must
|
|
read every piece of a document and report all well-formedness and validity
|
|
violations. Less is required of a non-validating processor; it need not read
|
|
any part of the document other than the document entity. This has two effects
|
|
that may be important to users of XML processors:</p><ul><li><p>Certain well-formedness errors, specifically those that require reading
|
|
external entities, <span>may fail to</span> be detected by a non-validating processor. Examples
|
|
include the constraints entitled <a href="#wf-entdeclared"><cite>Entity Declared</cite></a>, <a href="#textent"><cite>Parsed Entity</cite></a>, and <a href="#norecursion"><cite>No
|
|
Recursion</cite></a>, as well as some of the cases described as <a href="#forbidden"><cite>forbidden</cite></a> in <a href="#entproc"><b>4.4 XML Processor Treatment of Entities and References</b></a>.</p></li><li><p>The information passed from the processor to the application may
|
|
vary, depending on whether the processor reads parameter and external entities.
|
|
For example, a non-validating processor <span>may fail to</span> <a href="#AVNormalize"><cite>normalize</cite></a>
|
|
attribute values, <a href="#included"><cite>include</cite></a> the replacement
|
|
text of internal entities, or supply <a href="#sec-attr-defaults"><cite>default
|
|
attribute values</cite></a>, where doing so depends on having read declarations
|
|
in external or parameter entities.</p></li></ul><p>For maximum reliability in interoperating between different XML processors,
|
|
applications which use non-validating processors <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD NOT</em> rely on any behaviors
|
|
not required of such processors. Applications which require DTD facilities
|
|
not related to validation (such
|
|
as the declaration of default attributes and internal entities that are
|
|
or may be specified in
|
|
external entities <em class="rfc2119" title="Keyword in RFC 2119 context">SHOULD</em> use validating XML processors.</p></div></div><div class="div1"> <h2><a name="sec-notation" id="sec-notation" />6 Notation</h2><p>The formal grammar of XML is given in this specification using a simple
|
|
Extended Backus-Naur Form (EBNF) notation. Each rule in the grammar defines
|
|
one symbol, in the form</p><div class="exampleInner"><pre>symbol ::= expression</pre></div><p>Symbols are written with an initial capital letter if they are the
|
|
start symbol of a regular language, otherwise with an initial lowercase
|
|
letter. Literal strings are quoted.</p><p>Within the expression on the right-hand side of a rule, the following expressions
|
|
are used to match strings of one or more characters: </p><dl><dt class="label"><code>#xN</code></dt><dd><p>where <code>N</code> is a hexadecimal integer, the expression matches the character
|
|
<span>whose</span><span> number
|
|
(code point) in</span> ISO/IEC 10646 <span>is <code>N</code></span>. The number of leading zeros in the <code>#xN</code>
|
|
form is insignificant.</p></dd><dt class="label"><code>[a-zA-Z]</code>, <code>[#xN-#xN]</code></dt><dd><p>matches any <a href="#NT-Char">Char</a> with a value in the range(s) indicated (inclusive).</p></dd><dt class="label"><code>[abc]</code>, <code>[#xN#xN#xN]</code></dt><dd><p>matches any <a href="#NT-Char">Char</a> with a value among the characters
|
|
enumerated. Enumerations and ranges can be mixed in one set of brackets.</p></dd><dt class="label"><code>[^a-z]</code>, <code>[^#xN-#xN]</code></dt><dd><p>matches any <a href="#NT-Char">Char</a> with a value <em>outside</em> the range
|
|
indicated.</p></dd><dt class="label"><code>[^abc]</code>, <code>[^#xN#xN#xN]</code></dt><dd><p>matches any <a href="#NT-Char">Char</a> with a value not among the characters given. Enumerations
|
|
and ranges of forbidden values can be mixed in one set of brackets.</p></dd><dt class="label"><code>"string"</code></dt><dd><p>matches a literal string <a title="match" href="#dt-match">matching</a> that
|
|
given inside the double quotes.</p></dd><dt class="label"><code>'string'</code></dt><dd><p>matches a literal string <a title="match" href="#dt-match">matching</a> that
|
|
given inside the single quotes.</p></dd></dl><p> These symbols may be combined to match more complex patterns as follows,
|
|
where <code>A</code> and <code>B</code> represent simple expressions: </p><dl><dt class="label">(<code>expression</code>)</dt><dd><p><code>expression</code> is treated as a unit and may be combined as described
|
|
in this list.</p></dd><dt class="label"><code>A?</code></dt><dd><p>matches <code>A</code> or nothing; optional <code>A</code>.</p></dd><dt class="label"><code>A B</code></dt><dd><p>matches <code>A</code> followed by <code>B</code>. This
|
|
operator has higher precedence than alternation; thus <code>A B | C D</code>
|
|
is identical to <code>(A B) | (C D)</code>.</p></dd><dt class="label"><code>A | B</code></dt><dd><p>matches <code>A</code> or <code>B</code>.</p></dd><dt class="label"><code>A - B</code></dt><dd><p>matches any string that matches <code>A</code> but does not match <code>B</code>.</p></dd><dt class="label"><code>A+</code></dt><dd><p>matches one or more occurrences of <code>A</code>. Concatenation
|
|
has higher precedence than alternation; thus <code>A+ | B+</code> is identical
|
|
to <code>(A+) | (B+)</code>.</p></dd><dt class="label"><code>A*</code></dt><dd><p>matches zero or more occurrences of <code>A</code>. Concatenation
|
|
has higher precedence than alternation; thus <code>A* | B*</code> is identical
|
|
to <code>(A*) | (B*)</code>.</p></dd></dl><p> Other notations used in the productions are: </p><dl><dt class="label"><code>/* ... */</code></dt><dd><p>comment.</p></dd><dt class="label"><code>[ wfc: ... ]</code></dt><dd><p>well-formedness constraint; this identifies by name a constraint on <a title="Well-Formed" href="#dt-wellformed">well-formed</a> documents associated with a production.</p></dd><dt class="label"><code>[ vc: ... ]</code></dt><dd><p>validity constraint; this identifies by name a constraint on <a title="Validity" href="#dt-valid">valid</a>
|
|
documents associated with a production.</p></dd></dl><p></p></div></div><div class="back"><div class="div1"> <h2><a name="sec-bibliography" id="sec-bibliography" />A References</h2><div class="div2"> <h3><a name="sec-existing-stds" id="sec-existing-stds" />A.1 Normative References</h3><dl><dt class="label"><a name="IANA" id="IANA" />IANA-CHARSETS</dt><dd>(Internet
|
|
Assigned Numbers Authority) <a href="http://www.iana.org/assignments/character-sets"><cite>Official Names for Character Sets</cite></a>,
|
|
ed. Keld Simonsen et al. (See http://www.iana.org/assignments/character-sets.)</dd><dt class="label"><a name="rfc2119" id="rfc2119" />IETF RFC 2119</dt><dd>IETF
|
|
(Internet Engineering Task Force). <a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>RFC 2119: Key words for use in RFCs to Indicate Requirement Levels</cite></a>.
|
|
Scott Bradner, 1997. (See http://www.ietf.org/rfc/rfc2119.txt.)</dd><dt class="label"><a name="rfc2396" id="rfc2396" />IETF RFC 2396</dt><dd>IETF
|
|
(Internet Engineering Task Force). <a href="http://www.ietf.org/rfc/rfc2396.txt"><cite>RFC 2396: Uniform Resource Identifiers
|
|
(URI): Generic Syntax</cite></a>. T. Berners-Lee, R. Fielding, L. Masinter.
|
|
1998. (See http://www.ietf.org/rfc/rfc2396.txt.)</dd><dt class="label"><a name="rfc2732" id="rfc2732" />IETF RFC 2732</dt><dd>IETF
|
|
(Internet Engineering Task Force). <a href="http://www.ietf.org/rfc/rfc2732.txt"><cite>RFC 2732: Format for Literal
|
|
IPv6 Addresses in URL's</cite></a>. R. Hinden, B. Carpenter, L. Masinter.
|
|
1999. (See http://www.ietf.org/rfc/rfc2732.txt.)</dd><dt class="label"><a name="RFC1766" id="RFC1766" />IETF RFC 3066</dt><dd>IETF
|
|
(Internet Engineering Task Force). <a href="http://www.ietf.org/rfc/rfc3066.txt"><cite>RFC 3066: Tags for the Identification
|
|
of Languages</cite></a>, ed. H. Alvestrand. 2001. (See http://www.ietf.org/rfc/rfc3066.txt.)</dd><dt class="label"><a name="ISO10646" id="ISO10646" />ISO/IEC 10646</dt><dd><span>ISO (International
|
|
Organization for Standardization). <cite>ISO/IEC 10646-1:2000. Information
|
|
technology — Universal Multiple-Octet Coded Character Set (UCS) —
|
|
Part 1: Architecture and Basic Multilingual Plane</cite> and <cite>ISO/IEC 10646-2:2001.
|
|
Information technology — Universal Multiple-Octet Coded Character Set (UCS) — Part 2:
|
|
Supplementary Planes</cite>, as, from time to time, amended, replaced by a new edition or
|
|
expanded by the addition of new parts. [Geneva]: International Organization for Standardization.
|
|
(See <a href="http://www.iso.ch">http://www.iso.ch</a> for the latest version.)</span></dd><dt class="label"><a name="Unicode" id="Unicode" />Unicode</dt><dd>The Unicode Consortium. <em>The Unicode
|
|
Standard, Version 4.0.</em> Reading, Mass.: Addison-Wesley,
|
|
2003,
|
|
as updated from time to time by the publication of new versions. (See
|
|
<a href="http://www.unicode.org/unicode/standard/versions">
|
|
http://www.unicode.org/unicode/standard/versions</a> for the latest version
|
|
and additional information on versions of the standard and of the Unicode
|
|
Character Database).</dd><dt class="label"><a name="XML1.0" />XML-1.0</dt><dd>W3C. <a href="http://www.w3.org/TR/REC-xml"><cite>Extensible Markup Language (XML) 1.0 (Third
|
|
Edition)</cite></a>. Tim Bray, Jean Paoli, C.M. Sperberg-McQueen, Eve Maler, François Yergeau
|
|
(editors) (See http://www.w3.org/TR/REC-xml.)</dd></dl></div><div class="div2"> <h3><a name="null" id="null" />A.2 Other References</h3><dl><dt class="label"><a name="Aho" id="Aho" />Aho/Ullman</dt><dd>Aho, Alfred V., Ravi Sethi, and Jeffrey D.
|
|
Ullman. <cite>Compilers: Principles, Techniques, and Tools</cite>.
|
|
Reading: Addison-Wesley, 1986, rpt. corr. 1988.</dd><dt class="label"><a name="ABK" id="ABK" />Brüggemann-Klein</dt><dd>Brüggemann-Klein,
|
|
Anne. <a href="ftp://ftp.informatik.uni-freiburg.de/documents/papers/brueggem/habil.ps"><cite>Formal Models in Document Processing</cite></a>. Habilitationsschrift. Faculty
|
|
of Mathematics at the University of Freiburg, 1993. (See ftp://ftp.informatik.uni-freiburg.de/documents/papers/brueggem/habil.ps.)</dd><dt class="label"><a name="ABKDW" id="ABKDW" />Brüggemann-Klein and Wood</dt><dd>Brüggemann-Klein,
|
|
Anne, and Derick Wood. <cite>Deterministic Regular Languages</cite>.
|
|
Universität Freiburg, Institut für Informatik, Bericht 38, Oktober 1991. Extended
|
|
abstract in A. Finkel, M. Jantzen, Hrsg., STACS 1992, S. 173-184. Springer-Verlag,
|
|
Berlin 1992. Lecture Notes in Computer Science 577. Full version titled <cite>One-Unambiguous
|
|
Regular Languages</cite> in Information and Computation 140 (2): 229-253,
|
|
February 1998.</dd><dt class="label"><a name="Charmod" />Charmod</dt><dd>W3C Working Draft.
|
|
|
|
<a href="http://www.w3.org/TR/2003/WD-charmod-20030822/"><cite>Character Model for the World Wide Web 1.0</cite></a>.
|
|
|
|
Martin J. Dürst, François Yergeau, Richard Ishida, Misha Wolf, Tex Texin. (See http://www.w3.org/TR/2003/WD-charmod-20030822/.)</dd><dt class="label"><a name="Clark" id="Clark" />Clark</dt><dd>James Clark.
|
|
<a href="http://www.w3.org/TR/NOTE-sgml-xml-971215"><cite>Comparison of SGML and XML</cite></a>. (See http://www.w3.org/TR/NOTE-sgml-xml-971215.)</dd><dt class="label"><a name="IANA-LANGCODES" id="IANA-LANGCODES" />IANA-LANGCODES</dt><dd>(Internet
|
|
Assigned Numbers Authority) <a href="http://www.iana.org/assignments/language-tags"><cite>Registry of Language Tags</cite></a>,
|
|
ed. Keld Simonsen et al. (See http://www.iana.org/assignments/language-tags.)</dd><dt class="label"><a name="RFC2141" id="RFC2141" />IETF RFC 2141</dt><dd>IETF
|
|
(Internet Engineering Task Force). <a href="http://www.ietf.org/rfc/rfc2141.txt"><cite>RFC 2141: URN Syntax</cite></a>, ed.
|
|
R. Moats. 1997. (See http://www.ietf.org/rfc/rfc2141.txt.)</dd><dt class="label"><a name="rfc2376" id="rfc2376" />IETF RFC 3023</dt><dd>IETF
|
|
(Internet Engineering Task Force). <a href="http://www.ietf.org/rfc/rfc3023.txt"><cite>RFC 3023: XML Media Types</cite></a>.
|
|
eds. M. Murata, S. St.Laurent, D. Kohn. 2001. (See http://www.ietf.org/rfc/rfc3023.txt.)</dd><dt class="label"><a name="rfc2781" id="rfc2781" />IETF RFC 2781</dt><dd>IETF
|
|
(Internet Engineering Task Force). <a href="http://www.ietf.org/rfc/rfc2781.txt"><cite>RFC 2781: UTF-16, an encoding
|
|
of ISO 10646</cite></a>, ed. P. Hoffman, F. Yergeau. 2000. (See http://www.ietf.org/rfc/rfc2781.txt.)</dd><dt class="label"><a name="ISO639" id="ISO639" />ISO 639</dt><dd>(International Organization for Standardization).
|
|
<cite>ISO 639:1988 (E).
|
|
Code for the representation of names of languages.</cite> [Geneva]: International
|
|
Organization for Standardization, 1988.</dd><dt class="label"><a name="ISO3166" id="ISO3166" />ISO 3166</dt><dd>(International Organization for Standardization).
|
|
<cite>ISO 3166-1:1997
|
|
(E). Codes for the representation of names of countries and their subdivisions —
|
|
Part 1: Country codes</cite> [Geneva]: International Organization for
|
|
Standardization, 1997.</dd><dt class="label"><a name="ISO8879" id="ISO8879" />ISO 8879</dt><dd>ISO (International Organization for Standardization). <cite>ISO
|
|
8879:1986(E). Information processing — Text and Office Systems —
|
|
Standard Generalized Markup Language (SGML).</cite> First edition —
|
|
1986-10-15. [Geneva]: International Organization for Standardization, 1986. </dd><dt class="label"><a name="ISO10744" id="ISO10744" />ISO/IEC 10744</dt><dd>ISO (International Organization for
|
|
Standardization). <cite>ISO/IEC 10744-1992 (E). Information technology —
|
|
Hypermedia/Time-based Structuring Language (HyTime). </cite> [Geneva]:
|
|
International Organization for Standardization, 1992. <em>Extended Facilities
|
|
Annexe.</em> [Geneva]: International Organization for Standardization, 1996. </dd><dt class="label"><a name="websgml" id="websgml" />WEBSGML</dt><dd>ISO
|
|
(International Organization for Standardization). <a href="http://www.sgmlsource.com/8879/n0029.htm"><cite>ISO 8879:1986
|
|
TC2. Information technology — Document Description and Processing Languages</cite></a>.
|
|
[Geneva]: International Organization for Standardization, 1998. (See http://www.sgmlsource.com/8879/n0029.htm.)</dd><dt class="label"><a name="xml-names" id="xml-names" />XML Names</dt><dd>Tim Bray,
|
|
Dave Hollander, and Andrew Layman, editors. <a href="http://www.w3.org/TR/REC-xml-names/"><cite>Namespaces in XML</cite></a>.
|
|
Textuality, Hewlett-Packard, and Microsoft. World Wide Web Consortium, 1999. (See http://www.w3.org/TR/REC-xml-names/.)</dd></dl></div></div><div class="div1"> <h2><a name="sec-CharNorm" id="sec-CharNorm" />B Definitions for Character Normalization</h2><p>This appendix contains the necessary definitions for character normalization.
|
|
For additional background information and examples, see <a href="#Charmod">[Charmod]</a>.</p><p>
|
|
[<a name="dt-Uni-encform" id="dt-Uni-encform" title="Unicode encoding form">Definition</a>: Text is said to be
|
|
in a <b>Unicode encoding form</b> if it is encoded in
|
|
UTF-8, UTF-16 or UTF-32.]</p><p>
|
|
[<a name="dt-legacyenc" id="dt-legacyenc" title="legacy encoding">Definition</a>: <b>Legacy encoding</b>
|
|
is taken to mean any character encoding not based on Unicode.]</p><p>
|
|
[<a name="dt-normtransc" id="dt-normtransc" title="normalizing transcoder">Definition</a>: A
|
|
<b>normalizing transcoder</b> is a transcoder that converts from a
|
|
<a title="legacy encoding" href="#dt-legacyenc">legacy encoding</a> to a
|
|
<a title="Unicode encoding form" href="#dt-Uni-encform">Unicode encoding form</a> and
|
|
ensures that the result is in Unicode Normalization Form C
|
|
(see UAX #15 <a href="#Unicode">[Unicode]</a>).]</p><p>[<a name="dt-charesc" id="dt-charesc" title="character escape">Definition</a>: A <b>character escape</b>
|
|
is a syntactic device defined in a markup or programming language that allows
|
|
one or more of:]</p><ol type="1"><li><p>expressing syntax-significant characters while disregarding
|
|
their significance in the syntax of the language, or</p></li><li><p>expressing characters not representable in the character encoding
|
|
chosen for an instance of the language, or</p></li><li><p>expressing characters in general, without use of the corresponding
|
|
character codes.</p></li></ol><p>
|
|
[<a name="dt-certified" id="dt-certified" title="certified">Definition</a>: <b>Certified</b> text
|
|
is text which satisfies at least one of the following conditions:]</p><ol type="1"><li><p>it has been confirmed through inspection that the text
|
|
is in normalized form</p></li><li><p>the source text-processing component is identified
|
|
and is known to produce only normalized text.</p></li></ol><p>
|
|
[<a name="dt-uninorm" id="dt-uninorm" title="Unicode-normalized">Definition</a>: Text is, for the purposes of
|
|
this specification, <b>Unicode-normalized</b> if it is in a
|
|
<a title="Unicode encoding form" href="#dt-Uni-encform">Unicode encoding form</a> and is in
|
|
Unicode Normalization Form C, according to a version of Unicode Standard Annex #15:
|
|
Unicode Normalization Forms <a href="#Unicode">[Unicode]</a> at least as recent as the
|
|
oldest version of the Unicode Standard that contains all the characters
|
|
actually present in the text, but no earlier
|
|
than version 3.2.]</p><p>
|
|
[<a name="dt-inclnorm" id="dt-inclnorm" title="include-normalized">Definition</a>: Text is
|
|
<b>include-normalized</b> if:]</p><ol type="1"><li><p>the text is <a title="Unicode-normalized" href="#dt-uninorm">Unicode-normalized</a>
|
|
and does not contain any <a title="character escape" href="#dt-charesc">character escapes</a>
|
|
or <a title="Include" href="#dt-include">includes</a> whose expansion would
|
|
cause the text to become no longer <a title="Unicode-normalized" href="#dt-uninorm">Unicode-normalized</a>;
|
|
or</p></li><li><p>the text is in a <a title="legacy encoding" href="#dt-legacyenc">legacy encoding</a> and, if it were transcoded
|
|
to a <a title="Unicode encoding form" href="#dt-Uni-encform">Unicode encoding form</a> by a
|
|
<a title="normalizing transcoder" href="#dt-normtransc">normalizing transcoder</a>, the resulting
|
|
text would satisfy clause 1 above.</p></li></ol><p>
|
|
[<a name="dt-compchar" id="dt-compchar" title="composing character">Definition</a>: A <b>composing character</b>
|
|
is a character that is one or both of the following:]</p><ol type="1"><li><p>the second character in the canonical decomposition mapping of
|
|
some primary composite (as defined in D3 of UAX #15 <a href="#Unicode">[Unicode]</a>), or</p></li><li><p>of non-zero canonical combining class (as defined in Unicode
|
|
<a href="#Unicode">[Unicode]</a>).</p></li></ol><p>
|
|
[<a name="dt-fullnorm" id="dt-fullnorm" title="fully normalized">Definition</a>: Text is
|
|
<b>fully-normalized</b> if:]</p><ol type="1"><li><p>the text is in a <a title="Unicode encoding form" href="#dt-Uni-encform">Unicode encoding
|
|
form</a>, is <a title="include-normalized" href="#dt-inclnorm">include-normalized</a> and
|
|
none of the <a title="" href="#dt-relconst"><span>relevant</span>
|
|
constructs</a> comprising the text begin with a
|
|
<a title="composing character" href="#dt-compchar">composing character</a> or a
|
|
character escape representing a
|
|
<a title="composing character" href="#dt-compchar">composing character</a>; or</p></li><li><p>the text is in a <a title="legacy encoding" href="#dt-legacyenc">legacy encoding</a> and,
|
|
if it were transcoded to a <a title="Unicode encoding form" href="#dt-Uni-encform">Unicode encoding form</a>
|
|
by a <a title="normalizing transcoder" href="#dt-normtransc">normalizing transcoder</a>, the resulting text
|
|
would satisfy clause 1 above.</p></li></ol></div><div class="div1"> <h2><a name="sec-entexpand" id="sec-entexpand" />C Expansion of Entity and Character References (Non-Normative)</h2><p>This appendix contains some examples illustrating the sequence of entity-
|
|
and character-reference recognition and expansion, as specified in <a href="#entproc"><b>4.4 XML Processor Treatment of Entities and References</b></a>.</p><p>If the DTD contains the declaration</p><div class="exampleInner"><pre><!ENTITY example "<p>An ampersand (&#38;#38;) may be escaped
|
|
numerically (&#38;#38;#38;) or with a general entity
|
|
(&amp;amp;).</p>" ></pre></div><p>then the XML processor will recognize the character references when it
|
|
parses the entity declaration, and resolve them before storing the following
|
|
string as the value of the entity "<code>example</code>":</p><div class="exampleInner"><pre><p>An ampersand (&#38;) may be escaped
|
|
numerically (&#38;#38;) or with a general entity
|
|
(&amp;amp;).</p></pre></div><p>A reference in the document to "<code>&example;</code>"
|
|
will cause the text to be reparsed, at which time the start- and end-tags
|
|
of the <code>p</code> element will be recognized and the three references will
|
|
be recognized and expanded, resulting in a <code>p</code> element with the following
|
|
content (all data, no delimiters or markup):</p><div class="exampleInner"><pre>An ampersand (&) may be escaped
|
|
numerically (&#38;) or with a general entity
|
|
(&amp;).</pre></div><p>A more complex example will illustrate the rules and their effects fully.
|
|
In the following example, the line numbers are solely for reference.</p><div class="exampleInner"><pre>1 <?xml version='1.0'?>
|
|
2 <!DOCTYPE test [
|
|
3 <!ELEMENT test (#PCDATA) >
|
|
4 <!ENTITY % xx '&#37;zz;'>
|
|
5 <!ENTITY % zz '&#60;!ENTITY tricky "error-prone" >' >
|
|
6 %xx;
|
|
7 ]>
|
|
8 <test>This sample shows a &tricky; method.</test></pre></div><p>This produces the following:</p><ul><li><p>in line 4, the reference to character 37 is expanded immediately,
|
|
and the parameter entity "<code>xx</code>" is stored in the symbol
|
|
table with the value "<code>%zz;</code>". Since the replacement
|
|
text is not rescanned, the reference to parameter entity "<code>zz</code>"
|
|
is not recognized. (And it would be an error if it were, since "<code>zz</code>"
|
|
is not yet declared.)</p></li><li><p>in line 5, the character reference "<code>&#60;</code>"
|
|
is expanded immediately and the parameter entity "<code>zz</code>"
|
|
is stored with the replacement text "<code><!ENTITY tricky "error-prone"
|
|
></code>", which is a well-formed entity declaration.</p></li><li><p>in line 6, the reference to "<code>xx</code>" is recognized,
|
|
and the replacement text of "<code>xx</code>" (namely "<code>%zz;</code>")
|
|
is parsed. The reference to "<code>zz</code>" is recognized in
|
|
its turn, and its replacement text ("<code><!ENTITY tricky "error-prone"
|
|
></code>") is parsed. The general entity "<code>tricky</code>"
|
|
has now been declared, with the replacement text "<code>error-prone</code>".</p></li><li><p>in line 8, the reference to the general entity "<code>tricky</code>"
|
|
is recognized, and it is expanded, so the full content of the <code>test</code>
|
|
element is the self-describing (and ungrammatical) string <em>This sample
|
|
shows a error-prone method.</em></p></li></ul></div><div class="div1"> <h2><a name="determinism" id="determinism" />D Deterministic Content Models (Non-Normative)</h2><p>As
|
|
noted in <a href="#sec-element-content"><b>3.2.1 Element Content</b></a>, it is required that content
|
|
models in element type declarations be deterministic. This requirement is <a title="For Compatibility" href="#dt-compat">for compatibility</a> with SGML (which calls deterministic
|
|
content models "unambiguous"); XML processors built
|
|
using SGML systems may flag non-deterministic content models as errors.</p><p>For example, the content model <code>((b, c) | (b, d))</code> is non-deterministic,
|
|
because given an initial <code>b</code> the XML processor
|
|
cannot know which <code>b</code> in the model is being matched without looking
|
|
ahead to see which element follows the <code>b</code>. In this case, the two references
|
|
to <code>b</code> can be collapsed into a single reference, making the model read <code>(b,
|
|
(c | d))</code>. An initial <code>b</code> now clearly matches only a single name
|
|
in the content model. The processor doesn't need to look ahead to see what follows; either <code>c</code> or <code>d</code>
|
|
would be accepted.</p><p>More formally: a finite state automaton may be constructed from the content
|
|
model using the standard algorithms, e.g. algorithm 3.5 in section 3.9 of
|
|
Aho, Sethi, and Ullman <a href="#Aho">[Aho/Ullman]</a>. In many such algorithms, a follow
|
|
set is constructed for each position in the regular expression (i.e., each
|
|
leaf node in the syntax tree for the regular expression); if any position
|
|
has a follow set in which more than one following position is labeled with
|
|
the same element type name, then the content model is in error and may be
|
|
reported as an error.</p><p>Algorithms exist which allow many but not all non-deterministic content
|
|
models to be reduced automatically to equivalent deterministic models; see
|
|
Brüggemann-Klein 1991 <a href="#ABK">[Brüggemann-Klein]</a>.</p></div><div class="div1"> <h2><a name="sec-guessing" id="sec-guessing" />E Autodetection of Character Encodings (Non-Normative)</h2><p>The XML encoding declaration functions as an internal label on each entity,
|
|
indicating which character encoding is in use. Before an XML processor can
|
|
read the internal label, however, it apparently has to know what character
|
|
encoding is in use — which is what the internal label is trying to indicate.
|
|
In the general case, this is a hopeless situation. It is not entirely hopeless
|
|
in XML, however, because XML limits the general case in two ways: each implementation
|
|
is assumed to support only a finite set of character encodings, and the XML
|
|
encoding declaration is restricted in position and content in order to make
|
|
it feasible to autodetect the character encoding in use in each entity in
|
|
normal cases. Also, in many cases other sources of information are available
|
|
in addition to the XML data stream itself. Two cases may be distinguished,
|
|
depending on whether the XML entity is presented to the processor without,
|
|
or with, any accompanying (external) information. We consider the first case
|
|
first.</p><div class="div2"> <h3><a name="sec-guessing-no-ext-info" id="sec-guessing-no-ext-info" />E.1 Detection Without External Encoding Information</h3><p>Because each XML entity not accompanied by external
|
|
encoding information and not in UTF-8 or UTF-16 encoding must
|
|
begin with an XML encoding declaration, in which the first characters must
|
|
be '<code><?xml</code>', any conforming processor can detect, after two
|
|
to four octets of input, which of the following cases apply. In reading this
|
|
list, it may help to know that in UCS-4, '<' is "<code>#x0000003C</code>"
|
|
and '?' is "<code>#x0000003F</code>", and the Byte Order Mark
|
|
required of UTF-16 data streams is "<code>#xFEFF</code>". The notation
|
|
<var>##</var> is used to denote any byte value except that two consecutive
|
|
<var>##</var>s cannot be both 00.</p><p>With a Byte Order Mark:</p><table border="1" frame="border" summary="Encoding detection summary"><tbody><tr><td rowspan="1" colspan="1"><code>00 00 FE
|
|
FF</code></td><td rowspan="1" colspan="1">UCS-4, big-endian machine (1234 order)</td></tr><tr><td rowspan="1" colspan="1"><code>FF
|
|
FE 00 00</code></td><td rowspan="1" colspan="1">UCS-4, little-endian machine (4321 order)</td></tr><tr><td rowspan="1" colspan="1"><code>00 00 FF FE</code></td><td rowspan="1" colspan="1">UCS-4, unusual octet order (2143)</td></tr><tr><td rowspan="1" colspan="1"><code>FE FF 00 00</code></td><td rowspan="1" colspan="1">UCS-4, unusual octet order (3412)</td></tr><tr><td rowspan="1" colspan="1"><code>FE FF ## ##</code></td><td rowspan="1" colspan="1">UTF-16, big-endian</td></tr><tr><td rowspan="1" colspan="1"><code>FF FE ## ##</code></td><td rowspan="1" colspan="1">UTF-16, little-endian</td></tr><tr><td rowspan="1" colspan="1"><code>EF BB BF</code></td><td rowspan="1" colspan="1">UTF-8</td></tr></tbody></table><p>Without a Byte Order Mark:</p><table border="1" frame="border" summary="Encoding detection summary"><tbody><tr><td rowspan="1" colspan="1"><code>00 00 00 3C</code></td><td rowspan="4" colspan="1">UCS-4 or other encoding with a 32-bit code unit and ASCII
|
|
characters encoded as ASCII values, in respectively big-endian (1234), little-endian
|
|
(4321) and two unusual byte orders (2143 and 3412). The encoding declaration
|
|
must be read to determine which of UCS-4 or other supported 32-bit encodings
|
|
applies.</td></tr><tr><td rowspan="1" colspan="1"><code>3C 00 00 00</code></td></tr><tr><td rowspan="1" colspan="1"><code>00 00 3C 00</code></td></tr><tr><td rowspan="1" colspan="1"><code>00 3C 00 00</code></td></tr><tr><td rowspan="1" colspan="1"><code>00 3C 00 3F</code></td><td rowspan="1" colspan="1">UTF-16BE or big-endian ISO-10646-UCS-2
|
|
or other encoding with a 16-bit code unit in big-endian order and ASCII characters
|
|
encoded as ASCII values (the encoding declaration must be read to determine
|
|
which)</td></tr><tr><td rowspan="1" colspan="1"><code>3C 00 3F 00</code></td><td rowspan="1" colspan="1">UTF-16LE or little-endian
|
|
ISO-10646-UCS-2 or other encoding with a 16-bit code unit in little-endian
|
|
order and ASCII characters encoded as ASCII values (the encoding declaration
|
|
must be read to determine which)</td></tr><tr><td rowspan="1" colspan="1"><code>3C 3F 78 6D</code></td><td rowspan="1" colspan="1">UTF-8, ISO 646, ASCII, some part of ISO 8859, Shift-JIS, EUC, or any other
|
|
7-bit, 8-bit, or mixed-width encoding which ensures that the characters of
|
|
ASCII have their normal positions, width, and values; the actual encoding
|
|
declaration must be read to detect which of these applies, but since all of
|
|
these encodings use the same bit patterns for the relevant ASCII characters,
|
|
the encoding declaration itself may be read reliably</td></tr><tr><td rowspan="1" colspan="1"><code>4C
|
|
6F A7 94</code></td><td rowspan="1" colspan="1">EBCDIC (in some flavor; the full encoding declaration
|
|
must be read to tell which code page is in use)</td></tr><tr><td rowspan="1" colspan="1">Other</td><td rowspan="1" colspan="1">UTF-8 without an encoding declaration, or else the data stream is mislabeled
|
|
(lacking a required encoding declaration), corrupt, fragmentary, or enclosed
|
|
in a wrapper of some kind</td></tr></tbody></table><div class="note"><p class="prefix"><b>Note:</b></p><p>In cases above which do not require reading the encoding declaration to
|
|
determine the encoding, section 4.3.3 still requires that the encoding declaration,
|
|
if present, be read and that the encoding name be checked to match the actual
|
|
encoding of the entity. Also, it is possible that new character encodings
|
|
will be invented that will make it necessary to use the encoding declaration
|
|
to determine the encoding, in cases where this is not required at present.</p></div><p>This level of autodetection is enough to read the XML encoding declaration
|
|
and parse the character-encoding identifier, which is still necessary to distinguish
|
|
the individual members of each family of encodings (e.g. to tell UTF-8 from
|
|
8859, and the parts of 8859 from each other, or to distinguish the specific
|
|
EBCDIC code page in use, and so on).</p><p>Because the contents of the encoding declaration are restricted to characters
|
|
from the ASCII repertoire (however encoded),
|
|
a processor can reliably read the entire encoding declaration as soon as it
|
|
has detected which family of encodings is in use. Since in practice, all widely
|
|
used character encodings fall into one of the categories above, the XML encoding
|
|
declaration allows reasonably reliable in-band labeling of character encodings,
|
|
even when external sources of information at the operating-system or transport-protocol
|
|
level are unreliable. Character encodings such as UTF-7
|
|
that make overloaded usage of ASCII-valued bytes may fail to be reliably detected.</p><p>Once the processor has detected the character encoding in use, it can act
|
|
appropriately, whether by invoking a separate input routine for each case,
|
|
or by calling the proper conversion function on each character of input.</p><p>Like any self-labeling system, the XML encoding declaration will not work
|
|
if any software changes the entity's character set or encoding without updating
|
|
the encoding declaration. Implementors of character-encoding routines should
|
|
be careful to ensure the accuracy of the internal and external information
|
|
used to label the entity.</p></div><div class="div2"> <h3><a name="sec-guessing-with-ext-info" id="sec-guessing-with-ext-info" />E.2 Priorities in the Presence of External Encoding Information</h3><p>The second possible case occurs when the XML entity is accompanied by encoding
|
|
information, as in some file systems and some network protocols. When multiple
|
|
sources of information are available, their relative priority and the preferred
|
|
method of handling conflict should be specified as part of the higher-level
|
|
protocol used to deliver XML. In particular, please refer
|
|
to <a href="#rfc2376">[IETF RFC 3023]</a> or its successor, which defines the <code>text/xml</code>
|
|
and <code>application/xml</code> MIME types and provides some useful guidance.
|
|
In the interests of interoperability, however, the following rule is recommended.</p><ul><li><p>If an XML entity is in a file, the Byte-Order Mark and encoding declaration are used
|
|
(if present) to determine the character encoding.</p></li></ul></div></div><div class="div1"> <h2><a name="sec-xml-wg" id="sec-xml-wg" />F W3C XML Working Group (Non-Normative)</h2><p>This specification was prepared and approved for publication by the W3C
|
|
XML Working Group (WG). WG approval of this specification does not necessarily
|
|
imply that all WG participants voted for its approval. The current and former members
|
|
in the XML WG are:</p><ul><li>Jon Bosak, Sun (<i>Chair</i>) </li><li>James Clark (<i>Technical Lead</i>) </li><li>Tim Bray, Textuality and Netscape (<i>XML Co-editor</i>) </li><li>Jean Paoli, Microsoft (<i>XML
|
|
Co-editor</i>) </li><li>C. M. Sperberg-McQueen, U. of Ill. (<i>XML Co-editor</i>) </li><li>Dan Connolly, W3C (<i>W3C Liaison</i>) </li><li>Paula Angerstein, Texcel</li><li>Steve DeRose, INSO</li><li>Dave Hollander, HP</li><li>Eliot Kimber, ISOGEN</li><li>Eve Maler, ArborText</li><li>Tom Magliery, NCSA</li><li>Murray Maloney, SoftQuad, Grif
|
|
SA, Muzmo and Veo Systems</li><li>MURATA Makoto (FAMILY Given), Fuji
|
|
Xerox Information Systems</li><li>Joel Nava, Adobe</li><li>Conleth O'Connell, Vignette</li><li>Peter Sharpe, SoftQuad</li><li>John Tigue, DataChannel</li></ul></div><div class="div1"> <h2><a name="sec-core-wg" id="sec-core-wg" />G W3C XML Core <span>Working</span> Group (Non-Normative)</h2><p>The present edition of this specification was prepared by the W3C XML Core
|
|
Working Group (WG). The participants in the WG at the time of publication of this
|
|
edition were:</p><ul><li>Leonid Arbouzov, Sun Microsystems</li><li>Mary Brady</li><li>John Cowan (<i>XML 1.1 First Edition Editor</i>) </li><li>John Evdemon, Microsoft</li><li>Andrew Fang, Arbortext</li><li>Paul Grosso, Arbortext (<i>Co-Chair</i>) </li><li>Arnaud Le Hors, IBM</li><li>Dmitry Lenkov, Oracle</li><li>Anjana Manian, Oracle</li><li>Glenn Marcy, IBM</li><li>Jonathan Marsh, Microsoft</li><li>Sandra Martinez, NIST</li><li>Liam Quin, W3C (<i>Staff Contact</i>) </li><li>Lew Shannon</li><li>Richard Tobin, University of Edinburgh</li><li>Daniel Veillard</li><li>Norman Walsh, Sun Microsystems (<i>Co-Chair</i>) </li><li>François Yergeau</li></ul></div><div class="div1"> <h2><a name="prod-notes" id="prod-notes" />H Production Notes (Non-Normative)</h2><p>This edition was encoded in a
|
|
slightly modified version of the
|
|
<a href="http://www.w3.org/2002/xmlspec/dtd/2.5/xmlspec.dtd">XMLspec DTD, 2.5</a>.
|
|
The XHTML versions were produced with a combination of the
|
|
<a href="http://www.w3.org/2002/xmlspec/xhtml/1.9/xmlspec.xsl">xmlspec.xsl</a>,
|
|
<a href="http://www.w3.org/2002/xmlspec/xhtml/1.9/diffspec.xsl">diffspec.xsl</a>,
|
|
and <a href="REC-xml-3e.xsl">REC-xml-3e.xsl</a>
|
|
XSLT stylesheets.</p></div><div class="div1"> <h2><a name="sec-suggested-names" id="sec-suggested-names" />I Suggestions for XML Names (Non-Normative)</h2><p>The following suggestions define what is believed to be best
|
|
practice in the construction of XML names used as element names,
|
|
attribute names, processing instruction targets, entity names,
|
|
notation names, and the values of attributes of type ID, and are
|
|
intended as guidance for document authors and schema designers.
|
|
All references to Unicode are understood with respect to
|
|
a particular version of the Unicode Standard greater than or equal
|
|
to 3.0; which version should be used is left to the discretion of
|
|
the document author or schema designer.</p><p>The first two suggestions are directly derived from the rules
|
|
given for identifiers in the Unicode Standard, version 3.0, and
|
|
exclude all control characters, enclosing nonspacing marks,
|
|
non-decimal numbers, private-use characters, punctuation characters
|
|
(with the noted exceptions), symbol characters, unassigned
|
|
codepoints, and white space characters. The other suggestions
|
|
are mostly derived from <a href="#XML1.0">[XML-1.0]</a> Appendix B.</p><ol type="1"><li><p>The first character of any name should have a Unicode General
|
|
Category of Ll, Lu, Lo, Lm, Lt, or Nl, or else be '_' #x5F.</p></li><li><p>Characters other than the first should have a Unicode General
|
|
Category of Ll, Lu, Lo, Lm, Lt, Mc, Mn, Nl, Nd, Pc, or Cf, or else
|
|
be one of the following: '-' #x2D, '.' #x2E, ':' #x3A or
|
|
'·' #xB7 (middle dot). Since Cf characters are not
|
|
directly visible, they should be employed with caution and only
|
|
when necessary, to avoid creating names which are distinct to XML
|
|
processors but look the same to human beings.</p></li><li><p>Ideographic characters which have a canonical decomposition
|
|
(including those in the ranges [#xF900-#xFAFF] and
|
|
[#x2F800-#x2FFFD], with 12 exceptions) should not be used in names.
|
|
</p></li><li><p>Characters which have a compatibility decomposition (those with
|
|
a "compatibility formatting tag" in field 5 of the Unicode
|
|
Character Database -- marked by field 5 beginning with a "<")
|
|
should not be used in names. This suggestion does not apply
|
|
to #x0E33 THAI CHARACTER SARA AM or #x0EB3 LAO CHARACTER AM, which
|
|
despite their compatibility decompositions are in regular use in
|
|
those scripts.</p></li><li><p>Combining characters meant for use with symbols only (including
|
|
those in the ranges [#x20D0-#x20EF] and [#x1D165-#x1D1AD]) should
|
|
not be used in names.</p></li><li><p>The interlinear annotation characters ([#xFFF9-#xFFFB) should
|
|
not be used in names.</p></li><li><p>Variation selector characters should not be used in names.</p></li><li><p>Names which are nonsensical, unpronounceable, hard to read, or
|
|
easily confusable with other names should not be employed.</p></li></ol></div></div></body></html>
|