diff options
Diffstat (limited to 'result/valid/REC-xml-19980210.xml')
| -rw-r--r-- | result/valid/REC-xml-19980210.xml | 4154 |
1 files changed, 0 insertions, 4154 deletions
diff --git a/result/valid/REC-xml-19980210.xml b/result/valid/REC-xml-19980210.xml deleted file mode 100644 index f31e963..0000000 --- a/result/valid/REC-xml-19980210.xml +++ /dev/null @@ -1,4154 +0,0 @@ -<?xml version="1.0" encoding="ISO-8859-1" standalone="no"?> -<!DOCTYPE spec SYSTEM "dtds/spec.dtd" [ -<!-- LAST TOUCHED BY: Tim Bray, 8 February 1997 --><!-- The words 'FINAL EDIT' in comments mark places where changes -need to be made after approval of the document by the ERB, before -publication. --><!ENTITY XML.version "1.0"> -<!ENTITY doc.date "10 February 1998"> -<!ENTITY iso6.doc.date "19980210"> -<!ENTITY w3c.doc.date "02-Feb-1998"> -<!ENTITY draft.day "10"> -<!ENTITY draft.month "February"> -<!ENTITY draft.year "1998"> -<!ENTITY WebSGML "WebSGML Adaptations Annex to ISO 8879"> -<!ENTITY lt "<"> -<!ENTITY gt ">"> -<!ENTITY xmlpio "'<?xml'"> -<!ENTITY pic "'?>'"> -<!ENTITY br "\n"> -<!ENTITY cellback "#c0d9c0"> -<!ENTITY mdash "--"> -<!-- —, but nsgmls doesn't grok hex --><!ENTITY com "--"> -<!ENTITY como "--"> -<!ENTITY comc "--"> -<!ENTITY hcro "&#x"> -<!-- <!ENTITY nbsp " "> --><!ENTITY nbsp " "> -<!ENTITY magicents "<code>amp</code>, -<code>lt</code>, -<code>gt</code>, -<code>apos</code>, -<code>quot</code>"> -<!-- audience and distribution status: for use at publication time --><!ENTITY doc.audience "public review and discussion"> -<!ENTITY doc.distribution "may be distributed freely, as long as -all text and legal notices remain intact"> -]> -<!-- for Panorama *--> -<?VERBATIM "eg" ?> -<spec> -<header> -<title>Extensible Markup Language (XML) 1.0</title> -<version/> -<w3c-designation>REC-xml-&iso6.doc.date;</w3c-designation> -<w3c-doctype>W3C Recommendation</w3c-doctype> -<pubdate><day>&draft.day;</day><month>&draft.month;</month><year>&draft.year;</year></pubdate> - -<publoc> -<loc href="http://www.w3.org/TR/1998/REC-xml-&iso6.doc.date;"> -http://www.w3.org/TR/1998/REC-xml-&iso6.doc.date;</loc> -<loc href="http://www.w3.org/TR/1998/REC-xml-&iso6.doc.date;.xml"> -http://www.w3.org/TR/1998/REC-xml-&iso6.doc.date;.xml</loc> -<loc href="http://www.w3.org/TR/1998/REC-xml-&iso6.doc.date;.html"> -http://www.w3.org/TR/1998/REC-xml-&iso6.doc.date;.html</loc> -<loc href="http://www.w3.org/TR/1998/REC-xml-&iso6.doc.date;.pdf"> -http://www.w3.org/TR/1998/REC-xml-&iso6.doc.date;.pdf</loc> -<loc href="http://www.w3.org/TR/1998/REC-xml-&iso6.doc.date;.ps"> -http://www.w3.org/TR/1998/REC-xml-&iso6.doc.date;.ps</loc> -</publoc> -<latestloc> -<loc href="http://www.w3.org/TR/REC-xml"> -http://www.w3.org/TR/REC-xml</loc> -</latestloc> -<prevlocs> -<loc href="http://www.w3.org/TR/PR-xml-971208"> -http://www.w3.org/TR/PR-xml-971208</loc> -<!-- -<loc href='http://www.w3.org/TR/WD-xml-961114'> -http://www.w3.org/TR/WD-xml-961114</loc> -<loc href='http://www.w3.org/TR/WD-xml-lang-970331'> -http://www.w3.org/TR/WD-xml-lang-970331</loc> -<loc href='http://www.w3.org/TR/WD-xml-lang-970630'> -http://www.w3.org/TR/WD-xml-lang-970630</loc> -<loc href='http://www.w3.org/TR/WD-xml-970807'> -http://www.w3.org/TR/WD-xml-970807</loc> -<loc href='http://www.w3.org/TR/WD-xml-971117'> -http://www.w3.org/TR/WD-xml-971117</loc>--> -</prevlocs> -<authlist> -<author><name>Tim Bray</name> -<affiliation>Textuality and Netscape</affiliation> -<email href="mailto:tbray@textuality.com">tbray@textuality.com</email></author> -<author><name>Jean Paoli</name> -<affiliation>Microsoft</affiliation> -<email href="mailto:jeanpa@microsoft.com">jeanpa@microsoft.com</email></author> -<author><name>C. M. Sperberg-McQueen</name> -<affiliation>University of Illinois at Chicago</affiliation> -<email href="mailto:cmsmcq@uic.edu">cmsmcq@uic.edu</email></author> -</authlist> -<abstract> -<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> -</abstract> -<status> -<p>This document 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 W3C -XML Activity, details of which can be found at <loc href="http://www.w3.org/XML">http://www.w3.org/XML</loc>. A list of -current W3C Recommendations and other technical documents can be found -at <loc href="http://www.w3.org/TR">http://www.w3.org/TR</loc>. -</p> -<p>This specification uses the term URI, which is defined by <bibref ref="Berners-Lee"/>, a work in progress expected to update <bibref ref="RFC1738"/> and <bibref ref="RFC1808"/>. -</p> -<p>The list of known errors in this specification is -available at -<loc href="http://www.w3.org/XML/xml-19980210-errata">http://www.w3.org/XML/xml-19980210-errata</loc>.</p> -<p>Please report errors in this document to -<loc href="mailto:xml-editor@w3.org">xml-editor@w3.org</loc>. -</p> -</status> - - -<pubstmt> -<p>Chicago, Vancouver, Mountain View, et al.: -World-Wide Web Consortium, XML Working Group, 1996, 1997.</p> -</pubstmt> -<sourcedesc> -<p>Created in electronic form.</p> -</sourcedesc> -<langusage> -<language id="EN">English</language> -<language id="ebnf">Extended Backus-Naur Form (formal grammar)</language> -</langusage> -<revisiondesc> -<slist> -<sitem>1997-12-03 : CMSMcQ : yet further changes</sitem> -<sitem>1997-12-02 : TB : further changes (see TB to XML WG, -2 December 1997)</sitem> -<sitem>1997-12-02 : CMSMcQ : deal with as many corrections and -comments from the proofreaders as possible: -entify hard-coded document date in pubdate element, -change expansion of entity WebSGML, -update status description as per Dan Connolly (am not sure -about refernece to Berners-Lee et al.), -add 'The' to abstract as per WG decision, -move Relationship to Existing Standards to back matter and -combine with References, -re-order back matter so normative appendices come first, -re-tag back matter so informative appendices are tagged informdiv1, -remove XXX XXX from list of 'normative' specs in prose, -move some references from Other References to Normative References, -add RFC 1738, 1808, and 2141 to Other References (they are not -normative since we do not require the processor to enforce any -rules based on them), -add reference to 'Fielding draft' (Berners-Lee et al.), -move notation section to end of body, -drop URIchar non-terminal and use SkipLit instead, -lose stray reference to defunct nonterminal 'markupdecls', -move reference to Aho et al. into appendix (Tim's right), -add prose note saying that hash marks and fragment identifiers are -NOT part of the URI formally speaking, and are NOT legal in -system identifiers (processor 'may' signal an error). -Work through: -Tim Bray reacting to James Clark, -Tim Bray on his own, -Eve Maler, - -NOT DONE YET: -change binary / text to unparsed / parsed. -handle James's suggestion about < in attriubte values -uppercase hex characters, -namechar list, -</sitem> -<sitem>1997-12-01 : JB : add some column-width parameters</sitem> -<sitem>1997-12-01 : CMSMcQ : begin round of changes to incorporate -recent WG decisions and other corrections: -binding sources of character encoding info (27 Aug / 3 Sept), -correct wording of Faust quotation (restore dropped line), -drop SDD from EncodingDecl, -change text at version number 1.0, -drop misleading (wrong!) sentence about ignorables and extenders, -modify definition of PCData to make bar on msc grammatical, -change grammar's handling of internal subset (drop non-terminal markupdecls), -change definition of includeSect to allow conditional sections, -add integral-declaration constraint on internal subset, -drop misleading / dangerous sentence about relationship of -entities with system storage objects, -change table body tag to htbody as per EM change to DTD, -add rule about space normalization in public identifiers, -add description of how to generate our name-space rules from -Unicode character database (needs further work!). -</sitem> -<sitem>1997-10-08 : TB : Removed %-constructs again, new rules -for PE appearance.</sitem> -<sitem>1997-10-01 : TB : Case-sensitive markup; cleaned up -element-type defs, lotsa little edits for style</sitem> -<sitem>1997-09-25 : TB : Change to elm's new DTD, with -substantial detail cleanup as a side-effect</sitem> -<sitem>1997-07-24 : CMSMcQ : correct error (lost *) in definition -of ignoreSectContents (thanks to Makoto Murata)</sitem> -<sitem>Allow all empty elements to have end-tags, consistent with -SGML TC (as per JJC).</sitem> -<sitem>1997-07-23 : CMSMcQ : pre-emptive strike on pending corrections: -introduce the term 'empty-element tag', note that all empty elements -may use it, and elements declared EMPTY must use it. -Add WFC requiring encoding decl to come first in an entity. -Redefine notations to point to PIs as well as binary entities. -Change autodetection table by removing bytes 3 and 4 from -examples with Byte Order Mark. -Add content model as a term and clarify that it applies to both -mixed and element content. -</sitem> -<sitem>1997-06-30 : CMSMcQ : change date, some cosmetic changes, -changes to productions for choice, seq, Mixed, NotationType, -Enumeration. Follow James Clark's suggestion and prohibit -conditional sections in internal subset. TO DO: simplify -production for ignored sections as a result, since we don't -need to worry about parsers which don't expand PErefs finding -a conditional section.</sitem> -<sitem>1997-06-29 : TB : various edits</sitem> -<sitem>1997-06-29 : CMSMcQ : further changes: -Suppress old FINAL EDIT comments and some dead material. -Revise occurrences of % in grammar to exploit Henry Thompson's pun, -especially markupdecl and attdef. -Remove RMD requirement relating to element content (?). -</sitem> -<sitem>1997-06-28 : CMSMcQ : Various changes for 1 July draft: -Add text for draconian error handling (introduce -the term Fatal Error). -RE deleta est (changing wording from -original announcement to restrict the requirement to validating -parsers). -Tag definition of validating processor and link to it. -Add colon as name character. -Change def of %operator. -Change standard definitions of lt, gt, amp. -Strip leading zeros from #x00nn forms.</sitem> -<sitem>1997-04-02 : CMSMcQ : final corrections of editorial errors -found in last night's proofreading. Reverse course once more on -well-formed: Webster's Second hyphenates it, and that's enough -for me.</sitem> -<sitem>1997-04-01 : CMSMcQ : corrections from JJC, EM, HT, and self</sitem> -<sitem>1997-03-31 : Tim Bray : many changes</sitem> -<sitem>1997-03-29 : CMSMcQ : some Henry Thompson (on entity handling), -some Charles Goldfarb, some ERB decisions (PE handling in miscellaneous -declarations. Changed Ident element to accept def attribute. -Allow normalization of Unicode characters. move def of systemliteral -into section on literals.</sitem> -<sitem>1997-03-28 : CMSMcQ : make as many corrections as possible, from -Terry Allen, Norbert Mikula, James Clark, Jon Bosak, Henry Thompson, -Paul Grosso, and self. Among other things: give in on "well formed" -(Terry is right), tentatively rename QuotedCData as AttValue -and Literal as EntityValue to be more informative, since attribute -values are the <emph>only</emph> place QuotedCData was used, and -vice versa for entity text and Literal. (I'd call it Entity Text, -but 8879 uses that name for both internal and external entities.)</sitem> -<sitem>1997-03-26 : CMSMcQ : resynch the two forks of this draft, reapply -my changes dated 03-20 and 03-21. Normalize old 'may not' to 'must not' -except in the one case where it meant 'may or may not'.</sitem> -<sitem>1997-03-21 : TB : massive changes on plane flight from Chicago -to Vancouver</sitem> -<sitem>1997-03-21 : CMSMcQ : correct as many reported errors as possible. -</sitem> -<sitem>1997-03-20 : CMSMcQ : correct typos listed in CMSMcQ hand copy of spec.</sitem> -<sitem>1997-03-20 : CMSMcQ : cosmetic changes preparatory to revision for -WWW conference April 1997: restore some of the internal entity -references (e.g. to docdate, etc.), change character xA0 to &nbsp; -and define nbsp as &#160;, and refill a lot of paragraphs for -legibility.</sitem> -<sitem>1996-11-12 : CMSMcQ : revise using Tim's edits: -Add list type of NUMBERED and change most lists either to -BULLETS or to NUMBERED. -Suppress QuotedNames, Names (not used). -Correct trivial-grammar doc type decl. -Rename 'marked section' as 'CDATA section' passim. -Also edits from James Clark: -Define the set of characters from which [^abc] subtracts. -Charref should use just [0-9] not Digit. -Location info needs cleaner treatment: remove? (ERB -question). -One example of a PI has wrong pic. -Clarify discussion of encoding names. -Encoding failure should lead to unspecified results; don't -prescribe error recovery. -Don't require exposure of entity boundaries. -Ignore white space in element content. -Reserve entity names of the form u-NNNN. -Clarify relative URLs. -And some of my own: -Correct productions for content model: model cannot -consist of a name, so "elements ::= cp" is no good. -</sitem> -<sitem>1996-11-11 : CMSMcQ : revise for style. -Add new rhs to entity declaration, for parameter entities.</sitem> -<sitem>1996-11-10 : CMSMcQ : revise for style. -Fix / complete section on names, characters. -Add sections on parameter entities, conditional sections. -Still to do: Add compatibility note on deterministic content models. -Finish stylistic revision.</sitem> -<sitem>1996-10-31 : TB : Add Entity Handling section</sitem> -<sitem>1996-10-30 : TB : Clean up term & termdef. Slip in -ERB decision re EMPTY.</sitem> -<sitem>1996-10-28 : TB : Change DTD. Implement some of Michael's -suggestions. Change comments back to //. Introduce language for -XML namespace reservation. Add section on white-space handling. -Lots more cleanup.</sitem> -<sitem>1996-10-24 : CMSMcQ : quick tweaks, implement some ERB -decisions. Characters are not integers. Comments are /* */ not //. -Add bibliographic refs to 10646, HyTime, Unicode. -Rename old Cdata as MsData since it's <emph>only</emph> seen -in marked sections. Call them attribute-value pairs not -name-value pairs, except once. Internal subset is optional, needs -'?'. Implied attributes should be signaled to the app, not -have values supplied by processor.</sitem> -<sitem>1996-10-16 : TB : track down & excise all DSD references; -introduce some EBNF for entity declarations.</sitem> -<sitem>1996-10-?? : TB : consistency check, fix up scraps so -they all parse, get formatter working, correct a few productions.</sitem> -<sitem>1996-10-10/11 : CMSMcQ : various maintenance, stylistic, and -organizational changes: -Replace a few literals with xmlpio and -pic entities, to make them consistent and ensure we can change pic -reliably when the ERB votes. -Drop paragraph on recognizers from notation section. -Add match, exact match to terminology. -Move old 2.2 XML Processors and Apps into intro. -Mention comments, PIs, and marked sections in discussion of -delimiter escaping. -Streamline discussion of doctype decl syntax. -Drop old section of 'PI syntax' for doctype decl, and add -section on partial-DTD summary PIs to end of Logical Structures -section. -Revise DSD syntax section to use Tim's subset-in-a-PI -mechanism.</sitem> -<sitem>1996-10-10 : TB : eliminate name recognizers (and more?)</sitem> -<sitem>1996-10-09 : CMSMcQ : revise for style, consistency through 2.3 -(Characters)</sitem> -<sitem>1996-10-09 : CMSMcQ : re-unite everything for convenience, -at least temporarily, and revise quickly</sitem> -<sitem>1996-10-08 : TB : first major homogenization pass</sitem> -<sitem>1996-10-08 : TB : turn "current" attribute on div type into -CDATA</sitem> -<sitem>1996-10-02 : TB : remould into skeleton + entities</sitem> -<sitem>1996-09-30 : CMSMcQ : add a few more sections prior to exchange - with Tim.</sitem> -<sitem>1996-09-20 : CMSMcQ : finish transcribing notes.</sitem> -<sitem>1996-09-19 : CMSMcQ : begin transcribing notes for draft.</sitem> -<sitem>1996-09-13 : CMSMcQ : made outline from notes of 09-06, -do some housekeeping</sitem> -</slist> -</revisiondesc> -</header> -<body> -<div1 id="sec-intro"> -<head>Introduction</head> -<p>Extensible Markup Language, abbreviated XML, describes a class of -data objects called <termref def="dt-xml-doc">XML documents</termref> 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 <bibref ref="ISO8879"/>. -By construction, XML documents -are conforming SGML documents. -</p> -<p>XML documents are made up of storage units called <termref def="dt-entity">entities</termref>, which contain either parsed -or unparsed data. -Parsed data is made up of <termref def="dt-character">characters</termref>, -some -of which form <termref def="dt-chardata">character data</termref>, -and some of which form <termref def="dt-markup">markup</termref>. -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><termdef id="dt-xml-proc" term="XML Processor">A software module -called an <term>XML processor</term> is used to read XML documents -and provide access to their content and structure.</termdef> <termdef id="dt-app" term="Application">It is assumed that an XML processor is -doing its work on behalf of another module, called the -<term>application</term>.</termdef> 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> - -<div2 id="sec-origin-goals"> -<head>Origin and Goals</head> -<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 WG's contact with the W3C. -</p> -<p>The design goals for XML are:<olist> -<item><p>XML shall be straightforwardly usable over the -Internet.</p></item> -<item><p>XML shall support a wide variety of applications.</p></item> -<item><p>XML shall be compatible with SGML.</p></item> -<item><p>It shall be easy to write programs which process XML -documents.</p></item> -<item><p>The number of optional features in XML is to be kept to the -absolute minimum, ideally zero.</p></item> -<item><p>XML documents should be human-legible and reasonably -clear.</p></item> -<item><p>The XML design should be prepared quickly.</p></item> -<item><p>The design of XML shall be formal and concise.</p></item> -<item><p>XML documents shall be easy to create.</p></item> -<item><p>Terseness in XML markup is of minimal importance.</p></item></olist> -</p> -<p>This specification, -together with associated standards -(Unicode and ISO/IEC 10646 for characters, -Internet RFC 1766 for language identification tags, -ISO 639 for language name codes, and -ISO 3166 for country name codes), -provides all the information necessary to understand -XML Version &XML.version; -and construct computer programs to process it.</p> -<p>This version of the XML specification -<!-- is for &doc.audience;.--> -&doc.distribution;.</p> - -</div2> - - - - -<div2 id="sec-terminology"> -<head>Terminology</head> - -<p>The terminology used to describe XML documents is defined in the body of -this specification. -The terms defined in the following list are used in building those -definitions and in describing the actions of an XML processor: -<glist> -<gitem> -<label>may</label> -<def><p><termdef id="dt-may" term="May">Conforming documents and XML -processors are permitted to but need not behave as -described.</termdef></p></def> -</gitem> -<gitem> -<label>must</label> -<def><p>Conforming documents and XML processors -are required to behave as described; otherwise they are in error. -<!-- do NOT change this! this is what defines a violation of -a 'must' clause as 'an error'. -MSM --> -</p></def> -</gitem> -<gitem> -<label>error</label> -<def><p><termdef id="dt-error" term="Error">A violation of the rules of this -specification; results are -undefined. Conforming software may detect and report an error and may -recover from it.</termdef></p></def> -</gitem> -<gitem> -<label>fatal error</label> -<def><p><termdef id="dt-fatal" term="Fatal Error">An error -which a conforming <termref def="dt-xml-proc">XML processor</termref> -must detect and report to the application. -After encountering a fatal error, the -processor may continue -processing the data to search for further errors and may report such -errors to the application. In order to support correction of errors, -the processor may 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 must not -continue normal processing (i.e., it must not -continue to pass character data and information about the document's -logical structure to the application in the normal way). -</termdef></p></def> -</gitem> -<gitem> -<label>at user option</label> -<def><p>Conforming software may or must (depending on the modal verb in the -sentence) behave as described; if it does, it must -provide users a means to enable or disable the behavior -described.</p></def> -</gitem> -<gitem> -<label>validity constraint</label> -<def><p>A rule which applies to all -<termref def="dt-valid">valid</termref> XML documents. -Violations of validity constraints are errors; they must, at user option, -be reported by -<termref def="dt-validating">validating XML processors</termref>.</p></def> -</gitem> -<gitem> -<label>well-formedness constraint</label> -<def><p>A rule which applies to all <termref def="dt-wellformed">well-formed</termref> XML documents. -Violations of well-formedness constraints are -<termref def="dt-fatal">fatal errors</termref>.</p></def> -</gitem> - -<gitem> -<label>match</label> -<def><p><termdef id="dt-match" term="match">(Of strings or names:) -Two strings or names being compared must be identical. -Characters with multiple possible representations in ISO/IEC 10646 (e.g. -characters with -both precomposed and base+diacritic forms) match only if they have the -same representation in both strings. -At user option, processors may normalize such characters to -some canonical form. -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 -<specref ref="elementvalid"/>. -</termdef> -</p></def> -</gitem> -<gitem> -<label>for compatibility</label> -<def><p><termdef id="dt-compat" term="For Compatibility">A feature of -XML included solely to ensure that XML remains compatible with SGML. -</termdef></p></def> -</gitem> -<gitem> -<label>for interoperability</label> -<def><p><termdef id="dt-interop" term="For interoperability">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;.</termdef></p></def> -</gitem> -</glist> -</p> -</div2> - - -</div1> -<!-- &Docs; --> - -<div1 id="sec-documents"> -<head>Documents</head> - -<p><termdef id="dt-xml-doc" term="XML Document"> -A data object is an -<term>XML document</term> if it is -<termref def="dt-wellformed">well-formed</termref>, as -defined in this specification. -A well-formed XML document may in addition be -<termref def="dt-valid">valid</termref> if it meets certain further -constraints.</termdef></p> - -<p>Each XML document has both a logical and a physical structure. -Physically, the document is composed of units called <termref def="dt-entity">entities</termref>. An entity may <termref def="dt-entref">refer</termref> to other entities to cause their -inclusion in the document. A document begins in a "root" or <termref def="dt-docent">document entity</termref>. -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 must nest properly, as described -in <specref ref="wf-entities"/>. -</p> - -<div2 id="sec-well-formed"> -<head>Well-Formed XML Documents</head> - -<p><termdef id="dt-wellformed" term="Well-Formed"> -A textual object is -a well-formed XML document if:</termdef> -<olist> -<item><p>Taken as a whole, it -matches the production labeled <nt def="NT-document">document</nt>.</p></item> -<item><p>It -meets all the well-formedness constraints given in this specification.</p> -</item> -<item><p>Each of the <termref def="dt-parsedent">parsed entities</termref> -which is referenced directly or indirectly within the document is -<titleref href="wf-entities">well-formed</titleref>.</p></item> -</olist></p> -<p> -<scrap lang="ebnf" id="document"> -<head>Document</head> -<prod id="NT-document"><lhs>document</lhs> -<rhs><nt def="NT-prolog">prolog</nt> -<nt def="NT-element">element</nt> -<nt def="NT-Misc">Misc</nt>*</rhs></prod> -</scrap> -</p> -<p>Matching the <nt def="NT-document">document</nt> production -implies that: -<olist> -<item><p>It contains one or more -<termref def="dt-element">elements</termref>.</p> -</item> -<!--* N.B. some readers (notably JC) find the following -paragraph awkward and redundant. I agree it's logically redundant: -it *says* it is summarizing the logical implications of -matching the grammar, and that means by definition it's -logically redundant. I don't think it's rhetorically -redundant or unnecessary, though, so I'm keeping it. It -could however use some recasting when the editors are feeling -stronger. -MSM *--> -<item><p><termdef id="dt-root" term="Root Element">There is exactly -one element, called the <term>root</term>, or document element, no -part of which appears in the <termref def="dt-content">content</termref> of any other element.</termdef> -For all other elements, if the start-tag is in the content of another -element, the end-tag 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></item> -</olist> -</p> -<p><termdef id="dt-parentchild" term="Parent/Child">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 -<term>parent</term> of <code>C</code>, and <code>C</code> as a -<term>child</term> of <code>P</code>.</termdef></p></div2> - -<div2 id="charsets"> -<head>Characters</head> - -<p><termdef id="dt-text" term="Text">A parsed entity contains -<term>text</term>, a sequence of -<termref def="dt-character">characters</termref>, -which may represent markup or character data.</termdef> -<termdef id="dt-character" term="Character">A <term>character</term> -is an atomic unit of text as specified by -ISO/IEC 10646 <bibref ref="ISO10646"/>. -Legal characters are tab, carriage return, line feed, and the legal -graphic characters of Unicode and ISO/IEC 10646. -The use of "compatibility characters", as defined in section 6.8 -of <bibref ref="Unicode"/>, is discouraged. -</termdef> -<scrap lang="ebnf" id="char32"> -<head>Character Range</head> -<prodgroup pcw2="4" pcw4="17.5" pcw5="11"> -<prod id="NT-Char"><lhs>Char</lhs> -<rhs>#x9 | #xA | #xD | [#x20-#xD7FF] | [#xE000-#xFFFD] -| [#x10000-#x10FFFF]</rhs> -<com>any Unicode character, excluding the -surrogate blocks, FFFE, and FFFF.</com> </prod> -</prodgroup> -</scrap> -</p> - -<p>The mechanism for encoding character code points into bit patterns may -vary from entity to entity. All XML processors must accept the UTF-8 -and UTF-16 encodings of 10646; the mechanisms for signaling which of -the two is in use, or for bringing other encodings into play, are -discussed later, in <specref ref="charencoding"/>. -</p> -<!-- -<p>Regardless of the specific encoding used, any character in the ISO/IEC -10646 character set may be referred to by the decimal or hexadecimal -equivalent of its -UCS-4 code value. -</p>--> -</div2> - -<div2 id="sec-common-syn"> -<head>Common Syntactic Constructs</head> - -<p>This section defines some symbols used widely in the grammar.</p> -<p><nt def="NT-S">S</nt> (white space) consists of one or more space (#x20) -characters, carriage returns, line feeds, or tabs. - -<scrap lang="ebnf" id="white"> -<head>White Space</head> -<prodgroup pcw2="4" pcw4="17.5" pcw5="11"> -<prod id="NT-S"><lhs>S</lhs> -<rhs>(#x20 | #x9 | #xD | #xA)+</rhs> -</prod> -</prodgroup> -</scrap></p> -<p>Characters are classified for convenience as letters, digits, or other -characters. Letters consist of an alphabetic or syllabic -base character possibly -followed by one or more combining characters, or of an ideographic -character. -Full definitions of the specific characters in each class -are given in <specref ref="CharClasses"/>.</p> -<p><termdef id="dt-name" term="Name">A <term>Name</term> 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.</termdef> -Names beginning with the string "<code>xml</code>", or 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> -<note> -<p>The colon character within XML names is reserved for experimentation with -name spaces. -Its meaning is expected to be -standardized at some future point, at which point those documents -using the colon for experimental purposes may need to be updated. -(There is no guarantee that any name-space mechanism -adopted for XML will in fact use the colon as a name-space delimiter.) -In practice, this means that authors should not use the colon in XML -names except as part of name-space experiments, but that XML processors -should accept the colon as a name character.</p> -</note> -<p>An -<nt def="NT-Nmtoken">Nmtoken</nt> (name token) is any mixture of -name characters. -<scrap lang="ebnf"> -<head>Names and Tokens</head> -<prod id="NT-NameChar"><lhs>NameChar</lhs> -<rhs><nt def="NT-Letter">Letter</nt> -| <nt def="NT-Digit">Digit</nt> -| '.' | '-' | '_' | ':' -| <nt def="NT-CombiningChar">CombiningChar</nt> -| <nt def="NT-Extender">Extender</nt></rhs> -</prod> -<prod id="NT-Name"><lhs>Name</lhs> -<rhs>(<nt def="NT-Letter">Letter</nt> | '_' | ':') -(<nt def="NT-NameChar">NameChar</nt>)*</rhs></prod> -<prod id="NT-Names"><lhs>Names</lhs> -<rhs><nt def="NT-Name">Name</nt> -(<nt def="NT-S">S</nt> <nt def="NT-Name">Name</nt>)*</rhs></prod> -<prod id="NT-Nmtoken"><lhs>Nmtoken</lhs> -<rhs>(<nt def="NT-NameChar">NameChar</nt>)+</rhs></prod> -<prod id="NT-Nmtokens"><lhs>Nmtokens</lhs> -<rhs><nt def="NT-Nmtoken">Nmtoken</nt> (<nt def="NT-S">S</nt> <nt def="NT-Nmtoken">Nmtoken</nt>)*</rhs></prod> -</scrap> -</p> -<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 -(<nt def="NT-EntityValue">EntityValue</nt>), -the values of attributes (<nt def="NT-AttValue">AttValue</nt>), -and external identifiers -(<nt def="NT-SystemLiteral">SystemLiteral</nt>). -Note that a <nt def="NT-SystemLiteral">SystemLiteral</nt> -can be parsed without scanning for markup. -<scrap lang="ebnf"> -<head>Literals</head> -<prod id="NT-EntityValue"><lhs>EntityValue</lhs> -<rhs>'"' -([^%&"] -| <nt def="NT-PEReference">PEReference</nt> -| <nt def="NT-Reference">Reference</nt>)* -'"' -</rhs> -<rhs>| -"'" -([^%&'] -| <nt def="NT-PEReference">PEReference</nt> -| <nt def="NT-Reference">Reference</nt>)* -"'"</rhs> -</prod> -<prod id="NT-AttValue"><lhs>AttValue</lhs> -<rhs>'"' -([^<&"] -| <nt def="NT-Reference">Reference</nt>)* -'"' -</rhs> -<rhs>| -"'" -([^<&'] -| <nt def="NT-Reference">Reference</nt>)* -"'"</rhs> -</prod> -<prod id="NT-SystemLiteral"><lhs>SystemLiteral</lhs> -<rhs>('"' [^"]* '"') | ("'" [^']* "'") -</rhs> -</prod> -<prod id="NT-PubidLiteral"><lhs>PubidLiteral</lhs> -<rhs>'"' <nt def="NT-PubidChar">PubidChar</nt>* -'"' -| "'" (<nt def="NT-PubidChar">PubidChar</nt> - "'")* "'"</rhs> -</prod> -<prod id="NT-PubidChar"><lhs>PubidChar</lhs> -<rhs>#x20 | #xD | #xA -| [a-zA-Z0-9] -| [-'()+,./:=?;!*#@$_%]</rhs> -</prod> -</scrap> -</p> - -</div2> - -<div2 id="syntax"> -<head>Character Data and Markup</head> - -<p><termref def="dt-text">Text</termref> consists of intermingled -<termref def="dt-chardata">character -data</termref> and markup. -<termdef id="dt-markup" term="Markup"><term>Markup</term> takes the form of -<termref def="dt-stag">start-tags</termref>, -<termref def="dt-etag">end-tags</termref>, -<termref def="dt-empty">empty-element tags</termref>, -<termref def="dt-entref">entity references</termref>, -<termref def="dt-charref">character references</termref>, -<termref def="dt-comment">comments</termref>, -<termref def="dt-cdsection">CDATA section</termref> delimiters, -<termref def="dt-doctype">document type declarations</termref>, and -<termref def="dt-pi">processing instructions</termref>. -</termdef> -</p> -<p><termdef id="dt-chardata" term="Character Data">All text that is not markup -constitutes the <term>character data</term> of -the document.</termdef></p> -<p>The ampersand character (&) and the left angle bracket (<) -may appear in their literal form <emph>only</emph> when used as markup -delimiters, or within a <termref def="dt-comment">comment</termref>, a -<termref def="dt-pi">processing instruction</termref>, -or a <termref def="dt-cdsection">CDATA section</termref>. - -They are also legal within the <termref def="dt-litentval">literal entity -value</termref> of an internal entity declaration; see -<specref ref="wf-entities"/>. -<!-- FINAL EDIT: restore internal entity decl or leave it out. --> -If they are needed elsewhere, -they must be <termref def="dt-escape">escaped</termref> -using either <termref def="dt-charref">numeric character references</termref> -or the strings -"<code>&amp;</code>" and "<code>&lt;</code>" respectively. -The right angle -bracket (>) may be represented using the string -"<code>&gt;</code>", and must, <termref def="dt-compat">for -compatibility</termref>, -be escaped using -"<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 <termref def="dt-cdsection">CDATA section</termref>. -</p> -<p> -In the content of elements, character data -is any string of characters which does -not contain the start-delimiter of any markup. -In a CDATA section, character data -is any string of characters not including the CDATA-section-close -delimiter, "<code>]]></code>".</p> -<p> -To allow attribute values to contain both single and double quotes, the -apostrophe or single-quote character (') may be represented as -"<code>&apos;</code>", and the double-quote character (") as -"<code>&quot;</code>". -<scrap lang="ebnf"> -<head>Character Data</head> -<prod id="NT-CharData"> -<lhs>CharData</lhs> -<rhs>[^<&]* - ([^<&]* ']]>' [^<&]*)</rhs> -</prod> -</scrap> -</p> -</div2> - -<div2 id="sec-comments"> -<head>Comments</head> - -<p><termdef id="dt-comment" term="Comment"><term>Comments</term> may -appear anywhere in a document outside other -<termref def="dt-markup">markup</termref>; in addition, -they may appear within the document type declaration -at places allowed by the grammar. -They are not part of the document's <termref def="dt-chardata">character -data</termref>; an XML -processor may, but need not, make it possible for an application to -retrieve the text of comments. -<termref def="dt-compat">For compatibility</termref>, the string -"<code>--</code>" (double-hyphen) must not occur within -comments. -<scrap lang="ebnf"> -<head>Comments</head> -<prod id="NT-Comment"><lhs>Comment</lhs> -<rhs>'<!--' -((<nt def="NT-Char">Char</nt> - '-') -| ('-' (<nt def="NT-Char">Char</nt> - '-')))* -'-->'</rhs> -</prod> -</scrap> -</termdef></p> -<p>An example of a comment: -<eg><!&como; declarations for <head> & <body> &comc;></eg> -</p> -</div2> - -<div2 id="sec-pi"> -<head>Processing Instructions</head> - -<p><termdef id="dt-pi" term="Processing instruction"><term>Processing -instructions</term> (PIs) allow documents to contain instructions -for applications. - -<scrap lang="ebnf"> -<head>Processing Instructions</head> -<prod id="NT-PI"><lhs>PI</lhs> -<rhs>'<?' <nt def="NT-PITarget">PITarget</nt> -(<nt def="NT-S">S</nt> -(<nt def="NT-Char">Char</nt>* - -(<nt def="NT-Char">Char</nt>* &pic; <nt def="NT-Char">Char</nt>*)))? -&pic;</rhs></prod> -<prod id="NT-PITarget"><lhs>PITarget</lhs> -<rhs><nt def="NT-Name">Name</nt> - -(('X' | 'x') ('M' | 'm') ('L' | 'l'))</rhs> -</prod> -</scrap></termdef> -PIs are not part of the document's <termref def="dt-chardata">character -data</termref>, but must be passed through to the application. The -PI begins with a target (<nt def="NT-PITarget">PITarget</nt>) 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 <termref def="dt-notation">Notation</termref> mechanism -may be used for -formal declaration of PI targets. -</p> -</div2> - -<div2 id="sec-cdata-sect"> -<head>CDATA Sections</head> - -<p><termdef id="dt-cdsection" term="CDATA Section"><term>CDATA sections</term> -may 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>": -<scrap lang="ebnf"> -<head>CDATA Sections</head> -<prod id="NT-CDSect"><lhs>CDSect</lhs> -<rhs><nt def="NT-CDStart">CDStart</nt> -<nt def="NT-CData">CData</nt> -<nt def="NT-CDEnd">CDEnd</nt></rhs></prod> -<prod id="NT-CDStart"><lhs>CDStart</lhs> -<rhs>'<![CDATA['</rhs> -</prod> -<prod id="NT-CData"><lhs>CData</lhs> -<rhs>(<nt def="NT-Char">Char</nt>* - -(<nt def="NT-Char">Char</nt>* ']]>' <nt def="NT-Char">Char</nt>*)) -</rhs> -</prod> -<prod id="NT-CDEnd"><lhs>CDEnd</lhs> -<rhs>']]>'</rhs> -</prod> -</scrap> - -Within a CDATA section, only the <nt def="NT-CDEnd">CDEnd</nt> 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.</termdef> -</p> - -<p>An example of a CDATA section, in which "<code><greeting></code>" and -"<code></greeting></code>" -are recognized as <termref def="dt-chardata">character data</termref>, not -<termref def="dt-markup">markup</termref>: -<eg><![CDATA[<greeting>Hello, world!</greeting>]]></eg> -</p> -</div2> - -<div2 id="sec-prolog-dtd"> -<head>Prolog and Document Type Declaration</head> - -<p><termdef id="dt-xmldecl" term="XML Declaration">XML documents -may, and should, -begin with an <term>XML declaration</term> which specifies -the version of -XML being used.</termdef> -For example, the following is a complete XML document, <termref def="dt-wellformed">well-formed</termref> but not -<termref def="dt-valid">valid</termref>: -<eg><![CDATA[<?xml version="1.0"?> -<greeting>Hello, world!</greeting> -]]></eg> -and so is this: -<eg><![CDATA[<greeting>Hello, world!</greeting> -]]></eg> -</p> - -<p>The version number "<code>1.0</code>" should be used to indicate -conformance to this version of this specification; it is an error -for a document to use the value "<code>1.0</code>" -if it does not conform to this version of this specification. -It is the intent -of the XML working group to give later versions of this specification -numbers other than "<code>1.0</code>", but this intent does not -indicate a -commitment to produce any future versions of XML, nor if any are produced, to -use any particular numbering scheme. -Since future versions are not ruled out, this construct is provided -as a means to allow the possibility of automatic version recognition, should -it become necessary. -Processors may signal an error if they receive documents labeled with -versions they do not support. -</p> -<p>The function of the markup in an XML document is to describe its -storage and logical structure and to associate attribute-value pairs -with its logical structures. XML provides a mechanism, the <termref def="dt-doctype">document type declaration</termref>, to define -constraints on the logical structure and to support the use of -predefined storage units. - -<termdef id="dt-valid" term="Validity">An XML document is -<term>valid</term> if it has an associated document type -declaration and if the document -complies with the constraints expressed in it.</termdef></p> -<p>The document type declaration must appear before -the first <termref def="dt-element">element</termref> in the document. -<scrap lang="ebnf" id="xmldoc"> -<head>Prolog</head> -<prodgroup pcw2="6" pcw4="17.5" pcw5="9"> -<prod id="NT-prolog"><lhs>prolog</lhs> -<rhs><nt def="NT-XMLDecl">XMLDecl</nt>? -<nt def="NT-Misc">Misc</nt>* -(<nt def="NT-doctypedecl">doctypedecl</nt> -<nt def="NT-Misc">Misc</nt>*)?</rhs></prod> -<prod id="NT-XMLDecl"><lhs>XMLDecl</lhs> -<rhs>&xmlpio; -<nt def="NT-VersionInfo">VersionInfo</nt> -<nt def="NT-EncodingDecl">EncodingDecl</nt>? -<nt def="NT-SDDecl">SDDecl</nt>? -<nt def="NT-S">S</nt>? -&pic;</rhs> -</prod> -<prod id="NT-VersionInfo"><lhs>VersionInfo</lhs> -<rhs><nt def="NT-S">S</nt> 'version' <nt def="NT-Eq">Eq</nt> -(' <nt def="NT-VersionNum">VersionNum</nt> ' -| " <nt def="NT-VersionNum">VersionNum</nt> ")</rhs> -</prod> -<prod id="NT-Eq"><lhs>Eq</lhs> -<rhs><nt def="NT-S">S</nt>? '=' <nt def="NT-S">S</nt>?</rhs></prod> -<prod id="NT-VersionNum"> -<lhs>VersionNum</lhs> -<rhs>([a-zA-Z0-9_.:] | '-')+</rhs> -</prod> -<prod id="NT-Misc"><lhs>Misc</lhs> -<rhs><nt def="NT-Comment">Comment</nt> | <nt def="NT-PI">PI</nt> | -<nt def="NT-S">S</nt></rhs></prod> -</prodgroup> -</scrap></p> - -<p><termdef id="dt-doctype" term="Document Type Declaration">The XML -<term>document type declaration</term> -contains or points to -<termref def="dt-markupdecl">markup declarations</termref> -that provide a grammar for a -class of documents. -This grammar is known as a document type definition, -or <term>DTD</term>. -The document type declaration can point to an external subset (a -special kind of -<termref def="dt-extent">external entity</termref>) 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.</termdef> -</p> -<p><termdef id="dt-markupdecl" term="markup declaration"> -A <term>markup declaration</term> is -an <termref def="dt-eldecl">element type declaration</termref>, -an <termref def="dt-attdecl">attribute-list declaration</termref>, -an <termref def="dt-entdecl">entity declaration</termref>, or -a <termref def="dt-notdecl">notation declaration</termref>. -</termdef> -These declarations may be contained in whole or in part -within <termref def="dt-PE">parameter entities</termref>, -as described in the well-formedness and validity constraints below. -For fuller information, see -<specref ref="sec-physical-struct"/>.</p> -<scrap lang="ebnf" id="dtd"> -<head>Document Type Definition</head> -<prodgroup pcw2="6" pcw4="17.5" pcw5="9"> -<prod id="NT-doctypedecl"><lhs>doctypedecl</lhs> -<rhs>'<!DOCTYPE' <nt def="NT-S">S</nt> -<nt def="NT-Name">Name</nt> (<nt def="NT-S">S</nt> -<nt def="NT-ExternalID">ExternalID</nt>)? -<nt def="NT-S">S</nt>? ('[' -(<nt def="NT-markupdecl">markupdecl</nt> -| <nt def="NT-PEReference">PEReference</nt> -| <nt def="NT-S">S</nt>)* -']' -<nt def="NT-S">S</nt>?)? '>'</rhs> -<vc def="vc-roottype"/> -</prod> -<prod id="NT-markupdecl"><lhs>markupdecl</lhs> -<rhs><nt def="NT-elementdecl">elementdecl</nt> -| <nt def="NT-AttlistDecl">AttlistDecl</nt> -| <nt def="NT-EntityDecl">EntityDecl</nt> -| <nt def="NT-NotationDecl">NotationDecl</nt> -| <nt def="NT-PI">PI</nt> -| <nt def="NT-Comment">Comment</nt> -</rhs> -<vc def="vc-PEinMarkupDecl"/> -<wfc def="wfc-PEinInternalSubset"/> -</prod> - -</prodgroup> -</scrap> - -<p>The markup declarations may be made up in whole or in part of -the <termref def="dt-repltext">replacement text</termref> of -<termref def="dt-PE">parameter entities</termref>. -The productions later in this specification for -individual nonterminals (<nt def="NT-elementdecl">elementdecl</nt>, -<nt def="NT-AttlistDecl">AttlistDecl</nt>, and so on) describe -the declarations <emph>after</emph> all the parameter entities have been -<termref def="dt-include">included</termref>.</p> - -<vcnote id="vc-roottype"> -<head>Root Element Type</head> -<p> -The <nt def="NT-Name">Name</nt> in the document type declaration must -match the element type of the <termref def="dt-root">root element</termref>. -</p> -</vcnote> - -<vcnote id="vc-PEinMarkupDecl"> -<head>Proper Declaration/PE Nesting</head> -<p>Parameter-entity -<termref def="dt-repltext">replacement text</termref> must be properly nested -with markup declarations. -That is to say, if either the first character -or the last character of a markup -declaration (<nt def="NT-markupdecl">markupdecl</nt> above) -is contained in the replacement text for a -<termref def="dt-PERef">parameter-entity reference</termref>, -both must be contained in the same replacement text.</p> -</vcnote> -<wfcnote id="wfc-PEinInternalSubset"> -<head>PEs in Internal Subset</head> -<p>In the internal DTD subset, -<termref def="dt-PERef">parameter-entity references</termref> -can occur only where markup declarations can occur, not -within markup declarations. (This does not apply to -references that occur in -external parameter entities or to the external subset.) -</p> -</wfcnote> -<p> -Like the internal subset, the external subset and -any external parameter entities referred to in the DTD -must consist of a series of complete markup declarations of the types -allowed by the non-terminal symbol -<nt def="NT-markupdecl">markupdecl</nt>, interspersed with white space -or <termref def="dt-PERef">parameter-entity references</termref>. -However, portions of the contents -of the -external subset or of external parameter entities may conditionally be ignored -by using -the <termref def="dt-cond-section">conditional section</termref> -construct; this is not allowed in the internal subset. - -<scrap id="ext-Subset"> -<head>External Subset</head> -<prodgroup pcw2="6" pcw4="17.5" pcw5="9"> -<prod id="NT-extSubset"><lhs>extSubset</lhs> -<rhs><nt def="NT-TextDecl">TextDecl</nt>? -<nt def="NT-extSubsetDecl">extSubsetDecl</nt></rhs></prod> -<prod id="NT-extSubsetDecl"><lhs>extSubsetDecl</lhs> -<rhs>( -<nt def="NT-markupdecl">markupdecl</nt> -| <nt def="NT-conditionalSect">conditionalSect</nt> -| <nt def="NT-PEReference">PEReference</nt> -| <nt def="NT-S">S</nt> -)*</rhs> -</prod> -</prodgroup> -</scrap></p> -<p>The external subset and external parameter entities also differ -from the internal subset in that in them, -<termref def="dt-PERef">parameter-entity references</termref> -are permitted <emph>within</emph> markup declarations, -not only <emph>between</emph> markup declarations.</p> -<p>An example of an XML document with a document type declaration: -<eg><![CDATA[<?xml version="1.0"?> -<!DOCTYPE greeting SYSTEM "hello.dtd"> -<greeting>Hello, world!</greeting> -]]></eg> -The <termref def="dt-sysid">system identifier</termref> -"<code>hello.dtd</code>" gives the URI of a DTD for the document.</p> -<p>The declarations can also be given locally, as in this -example: -<eg><![CDATA[<?xml version="1.0" encoding="UTF-8" ?> -<!DOCTYPE greeting [ - <!ELEMENT greeting (#PCDATA)> -]> -<greeting>Hello, world!</greeting> -]]></eg> -If both the external and internal subsets are used, the -internal subset is considered to occur before the external subset. -<!-- 'is considered to'? boo. whazzat mean? --> -This has the effect that entity and attribute-list declarations in the -internal subset take precedence over those in the external subset. -</p> -</div2> - -<div2 id="sec-rmd"> -<head>Standalone Document Declaration</head> -<p>Markup declarations can affect the content of the document, -as passed from an <termref def="dt-xml-proc">XML processor</termref> -to an application; examples are attribute defaults and entity -declarations. -The standalone document declaration, -which may appear as a component of the XML declaration, signals -whether or not there are such declarations which appear external to -the <termref def="dt-docent">document entity</termref>. -<scrap lang="ebnf" id="fulldtd"> -<head>Standalone Document Declaration</head> -<prodgroup pcw2="4" pcw4="19.5" pcw5="9"> -<prod id="NT-SDDecl"><lhs>SDDecl</lhs> -<rhs> -<nt def="NT-S">S</nt> -'standalone' <nt def="NT-Eq">Eq</nt> -(("'" ('yes' | 'no') "'") | ('"' ('yes' | 'no') '"')) -</rhs> -<vc def="vc-check-rmd"/></prod> -</prodgroup> -</scrap></p> -<p> -In a standalone document declaration, the value "<code>yes</code>" indicates -that there -are no markup declarations external to the <termref def="dt-docent">document -entity</termref> (either in the DTD external subset, or in an -external parameter entity referenced from the internal subset) -which affect the information passed from the XML processor to -the application. -The value "<code>no</code>" indicates that there are or may be such -external markup declarations. -Note that the standalone document declaration only -denotes the presence of external <emph>declarations</emph>; the presence, in a -document, of -references to external <emph>entities</emph>, 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 "<code>no</code>" 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> -<vcnote id="vc-check-rmd"> -<head>Standalone Document Declaration</head> -<p>The standalone document declaration must have -the value "<code>no</code>" if any external markup declarations -contain declarations of:</p><ulist> -<item><p>attributes with <termref def="dt-default">default</termref> values, if -elements to which -these attributes apply appear in the document without -specifications of values for these attributes, or</p></item> -<item><p>entities (other than &magicents;), -if <termref def="dt-entref">references</termref> to those -entities appear in the document, or</p> -</item> -<item><p>attributes with values subject to -<titleref href="AVNormalize">normalization</titleref>, where the -attribute appears in the document with a value which will -change as a result of normalization, or</p> -</item> -<item> -<p>element types with <termref def="dt-elemcontent">element content</termref>, -if white space occurs -directly within any instance of those types. -</p></item> -</ulist> - -</vcnote> -<p>An example XML declaration with a standalone document declaration:<eg><?xml version="&XML.version;" standalone='yes'?></eg></p> -</div2> -<div2 id="sec-white-space"> -<head>White Space Handling</head> - -<p>In editing XML documents, it is often convenient to use "white space" -(spaces, tabs, and blank lines, denoted by the nonterminal -<nt def="NT-S">S</nt> in this specification) 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 <termref def="dt-xml-proc">XML processor</termref> -must always pass all characters in a document that are not -markup through to the application. A <termref def="dt-validating"> -validating XML processor</termref> must also inform the application -which of these characters constitute white space appearing -in <termref def="dt-elemcontent">element content</termref>. -</p> -<p>A special <termref def="dt-attr">attribute</termref> -named <kw>xml:space</kw> may 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, must be -<termref def="dt-attdecl">declared</termref> if it is used. -When declared, it must be given as an -<termref def="dt-enumerated">enumerated type</termref> whose only -possible values are "<code>default</code>" and "<code>preserve</code>". -For example:<eg><![CDATA[ <!ATTLIST poem xml:space (default|preserve) 'preserve'>]]></eg></p> -<p>The value "<code>default</code>" signals that applications' -default white-space processing modes are acceptable for this element; the -value "<code>preserve</code>" 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 overriden with another instance -of the <kw>xml:space</kw> attribute. -</p> -<p>The <termref def="dt-root">root element</termref> 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> - -</div2> -<div2 id="sec-line-ends"> -<head>End-of-Line Handling</head> -<p>XML <termref def="dt-parsedent">parsed entities</termref> 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 <termref def="dt-app">applications</termref>, -wherever an external parsed entity or the literal entity value -of an internal parsed entity contains either the literal -two-character sequence "#xD#xA" or a standalone literal -#xD, an <termref def="dt-xml-proc">XML processor</termref> must -pass to the application the single character #xA. -(This behavior can -conveniently be produced by normalizing all -line breaks to #xA on input, before parsing.) -</p> -</div2> -<div2 id="sec-lang-tag"> -<head>Language Identification</head> -<p>In document processing, it is often useful to -identify the natural or formal language -in which the content is -written. -A special <termref def="dt-attr">attribute</termref> named -<kw>xml:lang</kw> may 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, must be -<termref def="dt-attdecl">declared</termref> if it is used. -The values of the attribute are language identifiers as defined -by <bibref ref="RFC1766"/>, "Tags for the Identification of Languages": -<scrap lang="ebnf"> -<head>Language Identification</head> -<prod id="NT-LanguageID"><lhs>LanguageID</lhs> -<rhs><nt def="NT-Langcode">Langcode</nt> -('-' <nt def="NT-Subcode">Subcode</nt>)*</rhs></prod> -<prod id="NT-Langcode"><lhs>Langcode</lhs> -<rhs><nt def="NT-ISO639Code">ISO639Code</nt> | -<nt def="NT-IanaCode">IanaCode</nt> | -<nt def="NT-UserCode">UserCode</nt></rhs> -</prod> -<prod id="NT-ISO639Code"><lhs>ISO639Code</lhs> -<rhs>([a-z] | [A-Z]) ([a-z] | [A-Z])</rhs></prod> -<prod id="NT-IanaCode"><lhs>IanaCode</lhs> -<rhs>('i' | 'I') '-' ([a-z] | [A-Z])+</rhs></prod> -<prod id="NT-UserCode"><lhs>UserCode</lhs> -<rhs>('x' | 'X') '-' ([a-z] | [A-Z])+</rhs></prod> -<prod id="NT-Subcode"><lhs>Subcode</lhs> -<rhs>([a-z] | [A-Z])+</rhs></prod> -</scrap> -The <nt def="NT-Langcode">Langcode</nt> may be any of the following: -<ulist> -<item><p>a two-letter language code as defined by -<bibref ref="ISO639"/>, "Codes -for the representation of names of languages"</p></item> -<item><p>a language identifier registered with the Internet -Assigned Numbers Authority <bibref ref="IANA"/>; these begin with the -prefix "<code>i-</code>" (or "<code>I-</code>")</p></item> -<item><p>a language identifier assigned by the user, or agreed on -between parties in private use; these must begin with the -prefix "<code>x-</code>" or "<code>X-</code>" in order to ensure that they do not conflict -with names later standardized or registered with IANA</p></item> -</ulist></p> -<p>There may be any number of <nt def="NT-Subcode">Subcode</nt> segments; if -the first -subcode segment exists and the Subcode consists of two -letters, then it must be a country code from -<bibref ref="ISO3166"/>, "Codes -for the representation of names of countries." -If the first -subcode consists of more than two letters, it must be -a subcode for the language in question registered with IANA, -unless the <nt def="NT-Langcode">Langcode</nt> begins with the prefix -"<code>x-</code>" or -"<code>X-</code>". </p> -<p>It is customary to give the language code in lower case, and -the country code (if any) in upper case. -Note that these values, unlike other names in XML documents, -are case insensitive.</p> -<p>For example: -<eg><![CDATA[<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ßem Bemüh'n.</l> - </sp>]]></eg></p> -<!--<p>The xml:lang value is considered to apply both to the contents of an -element and -(unless otherwise via attribute default values) to the -values of all of its attributes with free-text (CDATA) values. --> -<p>The intent declared with <kw>xml:lang</kw> is considered to apply to -all attributes and content of the element where it is specified, -unless overridden with an instance of <kw>xml:lang</kw> -on another element within that content.</p> -<!-- -If no -value is specified for xml:lang on an element, and no default value is -defined for it in the DTD, then the xml:lang attribute of any element -takes the same value it has in the parent element, if any. The two -technical terms in the following example both have the same effective -value for xml:lang: - - <p xml:lang="en">Here the keywords are - <term xml:lang="en">shift</term> and - <term>reduce</term>. ...</p> - -The application, not the XML processor, is responsible for this ' -inheritance' of attribute values. ---> -<p>A simple declaration for <kw>xml:lang</kw> might take -the form -<eg>xml:lang NMTOKEN #IMPLIED</eg> -but specific default values may also be given, if appropriate. In a -collection of French poems for English students, with glosses and -notes in English, the xml:lang attribute might be declared this way: -<eg><![CDATA[ <!ATTLIST poem xml:lang NMTOKEN 'fr'> - <!ATTLIST gloss xml:lang NMTOKEN 'en'> - <!ATTLIST note xml:lang NMTOKEN 'en'>]]></eg> -</p> - -</div2> -</div1> -<!-- &Elements; --> - -<div1 id="sec-logical-struct"> -<head>Logical Structures</head> - -<p><termdef id="dt-element" term="Element">Each <termref def="dt-xml-doc">XML document</termref> contains one or more -<term>elements</term>, the boundaries of which are -either delimited by <termref def="dt-stag">start-tags</termref> -and <termref def="dt-etag">end-tags</termref>, or, for <termref def="dt-empty">empty</termref> elements, by an <termref def="dt-eetag">empty-element tag</termref>. Each element has a type, -identified by name, sometimes called its "generic -identifier" (GI), and may have a set of -attribute specifications.</termdef> Each attribute specification -has a <termref def="dt-attrname">name</termref> and a <termref def="dt-attrval">value</termref>. -</p> -<scrap lang="ebnf"><head>Element</head> -<prod id="NT-element"><lhs>element</lhs> -<rhs><nt def="NT-EmptyElemTag">EmptyElemTag</nt></rhs> -<rhs>| <nt def="NT-STag">STag</nt> <nt def="NT-content">content</nt> -<nt def="NT-ETag">ETag</nt></rhs> -<wfc def="GIMatch"/> -<vc def="elementvalid"/> -</prod> -</scrap> -<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> -<wfcnote id="GIMatch"> -<head>Element Type Match</head> -<p> -The <nt def="NT-Name">Name</nt> in an element's end-tag must match -the element type in -the start-tag. -</p> -</wfcnote> -<vcnote id="elementvalid"> -<head>Element Valid</head> -<p>An element is -valid if -there is a declaration matching -<nt def="NT-elementdecl">elementdecl</nt> where the -<nt def="NT-Name">Name</nt> matches the element type, and -one of the following holds:</p> -<olist> -<item><p>The declaration matches <kw>EMPTY</kw> and the element has no -<termref def="dt-content">content</termref>.</p></item> -<item><p>The declaration matches <nt def="NT-children">children</nt> and -the sequence of -<termref def="dt-parentchild">child elements</termref> -belongs to the language generated by the regular expression in -the content model, with optional white space (characters -matching the nonterminal <nt def="NT-S">S</nt>) between each pair -of child elements.</p></item> -<item><p>The declaration matches <nt def="NT-Mixed">Mixed</nt> and -the content consists of <termref def="dt-chardata">character -data</termref> and <termref def="dt-parentchild">child elements</termref> -whose types match names in the content model.</p></item> -<item><p>The declaration matches <kw>ANY</kw>, and the types -of any <termref def="dt-parentchild">child elements</termref> have -been declared.</p></item> -</olist> -</vcnote> - -<div2 id="sec-starttags"> -<head>Start-Tags, End-Tags, and Empty-Element Tags</head> - -<p><termdef id="dt-stag" term="Start-Tag">The beginning of every -non-empty XML element is marked by a <term>start-tag</term>. -<scrap lang="ebnf"> -<head>Start-tag</head> -<prodgroup pcw2="6" pcw4="15" pcw5="11.5"> -<prod id="NT-STag"><lhs>STag</lhs> -<rhs>'<' <nt def="NT-Name">Name</nt> -(<nt def="NT-S">S</nt> <nt def="NT-Attribute">Attribute</nt>)* -<nt def="NT-S">S</nt>? '>'</rhs> -<wfc def="uniqattspec"/> -</prod> -<prod id="NT-Attribute"><lhs>Attribute</lhs> -<rhs><nt def="NT-Name">Name</nt> <nt def="NT-Eq">Eq</nt> -<nt def="NT-AttValue">AttValue</nt></rhs> -<vc def="ValueType"/> -<wfc def="NoExternalRefs"/> -<wfc def="CleanAttrVals"/></prod> -</prodgroup> -</scrap> -The <nt def="NT-Name">Name</nt> in -the start- and end-tags gives the -element's <term>type</term>.</termdef> -<termdef id="dt-attr" term="Attribute"> -The <nt def="NT-Name">Name</nt>-<nt def="NT-AttValue">AttValue</nt> pairs are -referred to as -the <term>attribute specifications</term> of the element</termdef>, -<termdef id="dt-attrname" term="Attribute Name">with the -<nt def="NT-Name">Name</nt> in each pair -referred to as the <term>attribute name</term></termdef> and -<termdef id="dt-attrval" term="Attribute Value">the content of the -<nt def="NT-AttValue">AttValue</nt> (the text between the -<code>'</code> or <code>"</code> delimiters) -as the <term>attribute value</term>.</termdef> -</p> -<wfcnote id="uniqattspec"> -<head>Unique Att Spec</head> -<p> -No attribute name may appear more than once in the same start-tag -or empty-element tag. -</p> -</wfcnote> -<vcnote id="ValueType"> -<head>Attribute Value Type</head> -<p> -The attribute must have been declared; the value must be of the type -declared for it. -(For attribute types, see <specref ref="attdecls"/>.) -</p> -</vcnote> -<wfcnote id="NoExternalRefs"> -<head>No External Entity References</head> -<p> -Attribute values cannot contain direct or indirect entity references -to external entities. -</p> -</wfcnote> -<wfcnote id="CleanAttrVals"> -<head>No <code><</code> in Attribute Values</head> -<p>The <termref def="dt-repltext">replacement text</termref> of any entity -referred to directly or indirectly in an attribute -value (other than "<code>&lt;</code>") must not contain -a <code><</code>. -</p></wfcnote> -<p>An example of a start-tag: -<eg><termdef id="dt-dog" term="dog"></eg></p> -<p><termdef id="dt-etag" term="End Tag">The end of every element -that begins with a start-tag must -be marked by an <term>end-tag</term> -containing a name that echoes the element's type as given in the -start-tag: -<scrap lang="ebnf"> -<head>End-tag</head> -<prodgroup pcw2="6" pcw4="15" pcw5="11.5"> -<prod id="NT-ETag"><lhs>ETag</lhs> -<rhs>'</' <nt def="NT-Name">Name</nt> -<nt def="NT-S">S</nt>? '>'</rhs></prod> -</prodgroup> -</scrap> -</termdef></p> -<p>An example of an end-tag:<eg></termdef></eg></p> -<p><termdef id="dt-content" term="Content">The -<termref def="dt-text">text</termref> between the start-tag and -end-tag is called the element's -<term>content</term>: -<scrap lang="ebnf"> -<head>Content of Elements</head> -<prodgroup pcw2="6" pcw4="15" pcw5="11.5"> -<prod id="NT-content"><lhs>content</lhs> -<rhs>(<nt def="NT-element">element</nt> | <nt def="NT-CharData">CharData</nt> -| <nt def="NT-Reference">Reference</nt> | <nt def="NT-CDSect">CDSect</nt> -| <nt def="NT-PI">PI</nt> | <nt def="NT-Comment">Comment</nt>)*</rhs> -</prod> -</prodgroup> -</scrap> -</termdef></p> -<p><termdef id="dt-empty" term="Empty">If an element is <term>empty</term>, -it must be represented either by a start-tag immediately followed -by an end-tag or by an empty-element tag.</termdef> -<termdef id="dt-eetag" term="empty-element tag">An -<term>empty-element tag</term> takes a special form: -<scrap lang="ebnf"> -<head>Tags for Empty Elements</head> -<prodgroup pcw2="6" pcw4="15" pcw5="11.5"> -<prod id="NT-EmptyElemTag"><lhs>EmptyElemTag</lhs> -<rhs>'<' <nt def="NT-Name">Name</nt> (<nt def="NT-S">S</nt> -<nt def="NT-Attribute">Attribute</nt>)* <nt def="NT-S">S</nt>? -'/>'</rhs> -<wfc def="uniqattspec"/> -</prod> -</prodgroup> -</scrap> -</termdef></p> -<p>Empty-element tags may be used for any element which has no -content, whether or not it is declared using the keyword -<kw>EMPTY</kw>. -<termref def="dt-interop">For interoperability</termref>, the empty-element -tag must be used, and can only be used, for elements which are -<termref def="dt-eldecl">declared</termref> <kw>EMPTY</kw>.</p> -<p>Examples of empty elements: -<eg><IMG align="left" - src="http://www.w3.org/Icons/WWW/w3c_home" /> -<br></br> -<br/></eg></p> -</div2> - -<div2 id="elemdecls"> -<head>Element Type Declarations</head> - -<p>The <termref def="dt-element">element</termref> structure of an -<termref def="dt-xml-doc">XML document</termref> may, for -<termref def="dt-valid">validation</termref> purposes, -be constrained -using element type and attribute-list declarations. -An element type declaration constrains the element's -<termref def="dt-content">content</termref>. -</p> - -<p>Element type declarations often constrain which element types can -appear as <termref def="dt-parentchild">children</termref> of the element. -At user option, an XML processor may issue a warning -when a declaration mentions an element type for which no declaration -is provided, but this is not an error.</p> -<p><termdef id="dt-eldecl" term="Element Type declaration">An <term>element -type declaration</term> takes the form: -<scrap lang="ebnf"> -<head>Element Type Declaration</head> -<prodgroup pcw2="5.5" pcw4="18" pcw5="9"> -<prod id="NT-elementdecl"><lhs>elementdecl</lhs> -<rhs>'<!ELEMENT' <nt def="NT-S">S</nt> -<nt def="NT-Name">Name</nt> -<nt def="NT-S">S</nt> -<nt def="NT-contentspec">contentspec</nt> -<nt def="NT-S">S</nt>? '>'</rhs> -<vc def="EDUnique"/></prod> -<prod id="NT-contentspec"><lhs>contentspec</lhs> -<rhs>'EMPTY' -| 'ANY' -| <nt def="NT-Mixed">Mixed</nt> -| <nt def="NT-children">children</nt> -</rhs> -</prod> -</prodgroup> -</scrap> -where the <nt def="NT-Name">Name</nt> gives the element type -being declared.</termdef> -</p> - -<vcnote id="EDUnique"> -<head>Unique Element Type Declaration</head> -<p> -No element type may be declared more than once. -</p> -</vcnote> - -<p>Examples of element type declarations: -<eg><!ELEMENT br EMPTY> -<!ELEMENT p (#PCDATA|emph)* > -<!ELEMENT %name.para; %content.para; > -<!ELEMENT container ANY></eg></p> - -<div3 id="sec-element-content"> -<head>Element Content</head> - -<p><termdef id="dt-elemcontent" term="Element content">An element <termref def="dt-stag">type</termref> has -<term>element content</term> when elements of that -type must contain only <termref def="dt-parentchild">child</termref> -elements (no character data), optionally separated by -white space (characters matching the nonterminal -<nt def="NT-S">S</nt>). -</termdef> -In this case, the -constraint includes a content model, 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 (<nt def="NT-cp">cp</nt>s), which consist of names, -choice lists of content particles, or -sequence lists of content particles: -<scrap lang="ebnf"> -<head>Element-content Models</head> -<prodgroup pcw2="5.5" pcw4="16" pcw5="11"> -<prod id="NT-children"><lhs>children</lhs> -<rhs>(<nt def="NT-choice">choice</nt> -| <nt def="NT-seq">seq</nt>) -('?' | '*' | '+')?</rhs></prod> -<prod id="NT-cp"><lhs>cp</lhs> -<rhs>(<nt def="NT-Name">Name</nt> -| <nt def="NT-choice">choice</nt> -| <nt def="NT-seq">seq</nt>) -('?' | '*' | '+')?</rhs></prod> -<prod id="NT-choice"><lhs>choice</lhs> -<rhs>'(' <nt def="NT-S">S</nt>? cp -( <nt def="NT-S">S</nt>? '|' <nt def="NT-S">S</nt>? <nt def="NT-cp">cp</nt> )* -<nt def="NT-S">S</nt>? ')'</rhs> -<vc def="vc-PEinGroup"/></prod> -<prod id="NT-seq"><lhs>seq</lhs> -<rhs>'(' <nt def="NT-S">S</nt>? cp -( <nt def="NT-S">S</nt>? ',' <nt def="NT-S">S</nt>? <nt def="NT-cp">cp</nt> )* -<nt def="NT-S">S</nt>? ')'</rhs> -<vc def="vc-PEinGroup"/></prod> - -</prodgroup> -</scrap> -where each <nt def="NT-Name">Name</nt> is the type of an element which may -appear as a <termref def="dt-parentchild">child</termref>. -Any content -particle in a choice list may appear in the <termref def="dt-elemcontent">element content</termref> at the location where -the choice list appears in the grammar; -content particles occurring in a sequence list must each -appear in the <termref def="dt-elemcontent">element content</termref> 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 -must 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. <termref def="dt-compat">For compatibility</termref>, it is an error -if an element in the document can -match more than one occurrence of an element type in the content model. -For more information, see <specref ref="determinism"/>. -<!-- appendix <specref ref="determinism"/>. --> -<!-- appendix on deterministic content models. --> -</p> -<vcnote id="vc-PEinGroup"> -<head>Proper Group/PE Nesting</head> -<p>Parameter-entity -<termref def="dt-repltext">replacement text</termref> must be properly nested -with parenthetized groups. -That is to say, if either of the opening or closing parentheses -in a <nt def="NT-choice">choice</nt>, <nt def="NT-seq">seq</nt>, or -<nt def="NT-Mixed">Mixed</nt> construct -is contained in the replacement text for a -<termref def="dt-PERef">parameter entity</termref>, -both must be contained in the same replacement text.</p> -<p><termref def="dt-interop">For interoperability</termref>, -if a parameter-entity reference appears in a -<nt def="NT-choice">choice</nt>, <nt def="NT-seq">seq</nt>, or -<nt def="NT-Mixed">Mixed</nt> construct, its replacement text -should not be empty, and -neither the first nor last non-blank -character of the replacement text should be a connector -(<code>|</code> or <code>,</code>). -</p> -</vcnote> -<p>Examples of element-content models: -<eg><!ELEMENT spec (front, body, back?)> -<!ELEMENT div1 (head, (p | list | note)*, div2*)> -<!ELEMENT dictionary-body (%div.mix; | %dict.mix;)*></eg></p> -</div3> - -<div3 id="sec-mixed-content"> -<head>Mixed Content</head> - -<p><termdef id="dt-mixed" term="Mixed Content">An element -<termref def="dt-stag">type</termref> has -<term>mixed content</term> when elements of that type may contain -character data, optionally interspersed with -<termref def="dt-parentchild">child</termref> elements.</termdef> -In this case, the types of the child elements -may be constrained, but not their order or their number of occurrences: -<scrap lang="ebnf"> -<head>Mixed-content Declaration</head> -<prodgroup pcw2="5.5" pcw4="16" pcw5="11"> -<prod id="NT-Mixed"><lhs>Mixed</lhs> -<rhs>'(' <nt def="NT-S">S</nt>? -'#PCDATA' -(<nt def="NT-S">S</nt>? -'|' -<nt def="NT-S">S</nt>? -<nt def="NT-Name">Name</nt>)* -<nt def="NT-S">S</nt>? -')*' </rhs> -<rhs>| '(' <nt def="NT-S">S</nt>? '#PCDATA' <nt def="NT-S">S</nt>? ')' -</rhs><vc def="vc-PEinGroup"/> -<vc def="vc-MixedChildrenUnique"/> -</prod> - -</prodgroup> -</scrap> -where the <nt def="NT-Name">Name</nt>s give the types of elements -that may appear as children. -</p> -<vcnote id="vc-MixedChildrenUnique"> -<head>No Duplicate Types</head> -<p>The same name must not appear more than once in a single mixed-content -declaration. -</p></vcnote> -<p>Examples of mixed content declarations: -<eg><!ELEMENT p (#PCDATA|a|ul|b|i|em)*> -<!ELEMENT p (#PCDATA | %font; | %phrase; | %special; | %form;)* > -<!ELEMENT b (#PCDATA)></eg></p> -</div3> -</div2> - -<div2 id="attdecls"> -<head>Attribute-List Declarations</head> - -<p><termref def="dt-attr">Attributes</termref> are used to associate -name-value pairs with <termref def="dt-element">elements</termref>. -Attribute specifications may appear only within <termref def="dt-stag">start-tags</termref> -and <termref def="dt-eetag">empty-element tags</termref>; -thus, the productions used to -recognize them appear in <specref ref="sec-starttags"/>. -Attribute-list -declarations may be used: -<ulist> -<item><p>To define the set of attributes pertaining to a given -element type.</p></item> -<item><p>To establish type constraints for these -attributes.</p></item> -<item><p>To provide <termref def="dt-default">default values</termref> -for attributes.</p></item> -</ulist> -</p> -<p><termdef id="dt-attdecl" term="Attribute-List Declaration"> -<term>Attribute-list declarations</term> specify the name, data type, and default -value (if any) of each attribute associated with a given element type: -<scrap lang="ebnf"> -<head>Attribute-list Declaration</head> -<prod id="NT-AttlistDecl"><lhs>AttlistDecl</lhs> -<rhs>'<!ATTLIST' <nt def="NT-S">S</nt> -<nt def="NT-Name">Name</nt> -<nt def="NT-AttDef">AttDef</nt>* -<nt def="NT-S">S</nt>? '>'</rhs> -</prod> -<prod id="NT-AttDef"><lhs>AttDef</lhs> -<rhs><nt def="NT-S">S</nt> <nt def="NT-Name">Name</nt> -<nt def="NT-S">S</nt> <nt def="NT-AttType">AttType</nt> -<nt def="NT-S">S</nt> <nt def="NT-DefaultDecl">DefaultDecl</nt></rhs> -</prod> -</scrap> -The <nt def="NT-Name">Name</nt> in the -<nt def="NT-AttlistDecl">AttlistDecl</nt> rule is the type of an element. At -user option, an XML processor may issue a warning if attributes are -declared for an element type not itself declared, but this is not an -error. The <nt def="NT-Name">Name</nt> in the -<nt def="NT-AttDef">AttDef</nt> rule is -the name of the attribute.</termdef></p> -<p> -When more than one <nt def="NT-AttlistDecl">AttlistDecl</nt> 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. -<termref def="dt-interop">For interoperability,</termref> writers of DTDs -may choose to provide at most one attribute-list declaration -for a given element type, at most one attribute definition -for a given attribute name, and at least one attribute definition -in each attribute-list declaration. -For interoperability, an XML processor may 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> - -<div3 id="sec-attribute-types"> -<head>Attribute Types</head> - -<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, as noted: -<scrap lang="ebnf"> -<head>Attribute Types</head> -<prodgroup pcw4="14" pcw5="11.5"> -<prod id="NT-AttType"><lhs>AttType</lhs> -<rhs><nt def="NT-StringType">StringType</nt> -| <nt def="NT-TokenizedType">TokenizedType</nt> -| <nt def="NT-EnumeratedType">EnumeratedType</nt> -</rhs> -</prod> -<prod id="NT-StringType"><lhs>StringType</lhs> -<rhs>'CDATA'</rhs> -</prod> -<prod id="NT-TokenizedType"><lhs>TokenizedType</lhs> -<rhs>'ID'</rhs> -<vc def="id"/> -<vc def="one-id-per-el"/> -<vc def="id-default"/> -<rhs>| 'IDREF'</rhs> -<vc def="idref"/> -<rhs>| 'IDREFS'</rhs> -<vc def="idref"/> -<rhs>| 'ENTITY'</rhs> -<vc def="entname"/> -<rhs>| 'ENTITIES'</rhs> -<vc def="entname"/> -<rhs>| 'NMTOKEN'</rhs> -<vc def="nmtok"/> -<rhs>| 'NMTOKENS'</rhs> -<vc def="nmtok"/></prod> -</prodgroup> -</scrap> -</p> -<vcnote id="id"> -<head>ID</head> -<p> -Values of type <kw>ID</kw> must match the -<nt def="NT-Name">Name</nt> production. -A name must not appear more than once in -an XML document as a value of this type; i.e., ID values must uniquely -identify the elements which bear them. -</p> -</vcnote> -<vcnote id="one-id-per-el"> -<head>One ID per Element Type</head> -<p>No element type may have more than one ID attribute specified.</p> -</vcnote> -<vcnote id="id-default"> -<head>ID Attribute Default</head> -<p>An ID attribute must have a declared default of <kw>#IMPLIED</kw> or -<kw>#REQUIRED</kw>.</p> -</vcnote> -<vcnote id="idref"> -<head>IDREF</head> -<p> -Values of type <kw>IDREF</kw> must match -the <nt def="NT-Name">Name</nt> production, and -values of type <kw>IDREFS</kw> must match -<nt def="NT-Names">Names</nt>; -each <nt def="NT-Name">Name</nt> must match the value of an ID attribute on -some element in the XML document; i.e. <kw>IDREF</kw> values must -match the value of some ID attribute. -</p> -</vcnote> -<vcnote id="entname"> -<head>Entity Name</head> -<p> -Values of type <kw>ENTITY</kw> -must match the <nt def="NT-Name">Name</nt> production, -values of type <kw>ENTITIES</kw> must match -<nt def="NT-Names">Names</nt>; -each <nt def="NT-Name">Name</nt> must -match the -name of an <termref def="dt-unparsed">unparsed entity</termref> declared in the -<termref def="dt-doctype">DTD</termref>. -</p> -</vcnote> -<vcnote id="nmtok"> -<head>Name Token</head> -<p> -Values of type <kw>NMTOKEN</kw> must match the -<nt def="NT-Nmtoken">Nmtoken</nt> production; -values of type <kw>NMTOKENS</kw> must -match <termref def="NT-Nmtokens">Nmtokens</termref>. -</p> -</vcnote> -<!-- why? -<p>The XML processor must normalize attribute values before -passing them to the application, as described in -<specref ref="AVNormalize"/>.</p>--> -<p><termdef id="dt-enumerated" term="Enumerated Attribute Values"><term>Enumerated attributes</term> can take one -of a list of values provided in the declaration</termdef>. There are two -kinds of enumerated types: -<scrap lang="ebnf"> -<head>Enumerated Attribute Types</head> -<prod id="NT-EnumeratedType"><lhs>EnumeratedType</lhs> -<rhs><nt def="NT-NotationType">NotationType</nt> -| <nt def="NT-Enumeration">Enumeration</nt> -</rhs></prod> -<prod id="NT-NotationType"><lhs>NotationType</lhs> -<rhs>'NOTATION' -<nt def="NT-S">S</nt> -'(' -<nt def="NT-S">S</nt>? -<nt def="NT-Name">Name</nt> -(<nt def="NT-S">S</nt>? '|' <nt def="NT-S">S</nt>? -<nt def="NT-Name">Name</nt>)* -<nt def="NT-S">S</nt>? ')' -</rhs> -<vc def="notatn"/></prod> -<prod id="NT-Enumeration"><lhs>Enumeration</lhs> -<rhs>'(' <nt def="NT-S">S</nt>? -<nt def="NT-Nmtoken">Nmtoken</nt> -(<nt def="NT-S">S</nt>? '|' -<nt def="NT-S">S</nt>? -<nt def="NT-Nmtoken">Nmtoken</nt>)* -<nt def="NT-S">S</nt>? -')'</rhs> -<vc def="enum"/></prod> -</scrap> -A <kw>NOTATION</kw> attribute identifies a -<termref def="dt-notation">notation</termref>, 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> - -<vcnote id="notatn"> -<head>Notation Attributes</head> -<p> -Values of this type must match -one of the <titleref href="Notations">notation</titleref> names included in -the declaration; all notation names in the declaration must -be declared. -</p> -</vcnote> -<vcnote id="enum"> -<head>Enumeration</head> -<p> -Values of this type -must match one of the <nt def="NT-Nmtoken">Nmtoken</nt> tokens in the -declaration. -</p> -</vcnote> -<p><termref def="dt-interop">For interoperability,</termref> the same -<nt def="NT-Nmtoken">Nmtoken</nt> should not occur more than once in the -enumerated attribute types of a single element type. -</p> -</div3> - -<div3 id="sec-attr-defaults"> -<head>Attribute Defaults</head> - -<p>An <termref def="dt-attdecl">attribute declaration</termref> provides -information on whether -the attribute's presence is required, and if not, how an XML processor should -react if a declared attribute is absent in a document. -<scrap lang="ebnf"> -<head>Attribute Defaults</head> -<prodgroup pcw4="14" pcw5="11.5"> -<prod id="NT-DefaultDecl"><lhs>DefaultDecl</lhs> -<rhs>'#REQUIRED' -| '#IMPLIED' </rhs> -<rhs>| (('#FIXED' S)? <nt def="NT-AttValue">AttValue</nt>)</rhs> -<vc def="RequiredAttr"/> -<vc def="defattrvalid"/> -<wfc def="CleanAttrVals"/> -<vc def="FixedAttr"/> -</prod> -</prodgroup> -</scrap> - -</p> -<p>In an attribute declaration, <kw>#REQUIRED</kw> means that the -attribute must always be provided, <kw>#IMPLIED</kw> that no default -value is provided. -<!-- not any more!! -<kw>#IMPLIED</kw> means that if the attribute is omitted -from an element of this type, -the XML processor must inform the application -that no value was specified; no constraint is placed on the behavior -of the application. --> -<termdef id="dt-default" term="Attribute Default">If the -declaration -is neither <kw>#REQUIRED</kw> nor <kw>#IMPLIED</kw>, then the -<nt def="NT-AttValue">AttValue</nt> value contains the declared -<term>default</term> value; the <kw>#FIXED</kw> keyword states that -the attribute must always have the default value. -If a default value -is declared, when an XML processor encounters an omitted attribute, it -is to behave as though the attribute were present with -the declared default value.</termdef></p> -<vcnote id="RequiredAttr"> -<head>Required Attribute</head> -<p>If the default declaration is the keyword <kw>#REQUIRED</kw>, then -the attribute must be specified for -all elements of the type in the attribute-list declaration. -</p></vcnote> -<vcnote id="defattrvalid"> -<head>Attribute Default Legal</head> -<p> -The declared -default value must meet the lexical constraints of the declared attribute type. -</p> -</vcnote> -<vcnote id="FixedAttr"> -<head>Fixed Attribute Default</head> -<p>If an attribute has a default value declared with the -<kw>#FIXED</kw> keyword, instances of that attribute must -match the default value. -</p></vcnote> - -<p>Examples of attribute-list declarations: -<eg><!ATTLIST termdef - id ID #REQUIRED - name CDATA #IMPLIED> -<!ATTLIST list - type (bullets|ordered|glossary) "ordered"> -<!ATTLIST form - method CDATA #FIXED "POST"></eg></p> -</div3> -<div3 id="AVNormalize"> -<head>Attribute-Value Normalization</head> -<p>Before the value of an attribute is passed to the application -or checked for validity, the -XML processor must normalize it as follows: -<ulist> -<item><p>a character reference is processed by appending the referenced -character to the attribute value</p></item> -<item><p>an entity reference is processed by recursively processing the -replacement text of the entity</p></item> -<item><p>a whitespace character (#x20, #xD, #xA, #x9) is processed by -appending #x20 to the normalized value, except that only a single #x20 -is appended for a "#xD#xA" sequence that is part of an external -parsed entity or the literal entity value of an internal parsed -entity</p></item> -<item><p>other characters are processed by appending them to the normalized -value</p> -</item></ulist> -</p> -<p>If the declared value is not CDATA, then the XML processor must -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> -All attributes for which no declaration has been read should be treated -by a non-validating parser as if declared -<kw>CDATA</kw>. -</p> -</div3> -</div2> -<div2 id="sec-condition-sect"> -<head>Conditional Sections</head> -<p><termdef id="dt-cond-section" term="conditional section"> -<term>Conditional sections</term> are portions of the -<termref def="dt-doctype">document type declaration external subset</termref> -which are -included in, or excluded from, the logical structure of the DTD based on -the keyword which governs them.</termdef> -<scrap lang="ebnf"> -<head>Conditional Section</head> -<prodgroup pcw2="9" pcw4="14.5"> -<prod id="NT-conditionalSect"><lhs>conditionalSect</lhs> -<rhs><nt def="NT-includeSect">includeSect</nt> -| <nt def="NT-ignoreSect">ignoreSect</nt> -</rhs> -</prod> -<prod id="NT-includeSect"><lhs>includeSect</lhs> -<rhs>'<![' S? 'INCLUDE' S? '[' - -<nt def="NT-extSubsetDecl">extSubsetDecl</nt> -']]>' -</rhs> -</prod> -<prod id="NT-ignoreSect"><lhs>ignoreSect</lhs> -<rhs>'<![' S? 'IGNORE' S? '[' -<nt def="NT-ignoreSectContents">ignoreSectContents</nt>* -']]>'</rhs> -</prod> - -<prod id="NT-ignoreSectContents"><lhs>ignoreSectContents</lhs> -<rhs><nt def="NT-Ignore">Ignore</nt> -('<![' <nt def="NT-ignoreSectContents">ignoreSectContents</nt> ']]>' -<nt def="NT-Ignore">Ignore</nt>)*</rhs></prod> -<prod id="NT-Ignore"><lhs>Ignore</lhs> -<rhs><nt def="NT-Char">Char</nt>* - -(<nt def="NT-Char">Char</nt>* ('<![' | ']]>') -<nt def="NT-Char">Char</nt>*) -</rhs></prod> - -</prodgroup> -</scrap> -</p> -<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 <kw>INCLUDE</kw>, then the contents of the conditional -section are part of the DTD. -If the keyword of the conditional -section is <kw>IGNORE</kw>, then the contents of the conditional section are -not logically part of the DTD. -Note that for reliable parsing, the contents of even ignored -conditional sections must be read in order to -detect nested conditional sections and ensure that the end of the -outermost (ignored) conditional section is properly detected. -If a conditional section with a -keyword of <kw>INCLUDE</kw> occurs within a larger conditional -section with a keyword of <kw>IGNORE</kw>, both the outer and the -inner conditional sections are ignored.</p> -<p>If the keyword of the conditional section is a -parameter-entity reference, the parameter entity must be replaced by its -content before the processor decides whether to -include or ignore the conditional section.</p> -<p>An example: -<eg><!ENTITY % draft 'INCLUDE' > -<!ENTITY % final 'IGNORE' > - -<![%draft;[ -<!ELEMENT book (comments*, title, body, supplements?)> -]]> -<![%final;[ -<!ELEMENT book (title, body, supplements?)> -]]> -</eg> -</p> -</div2> - - -<!-- -<div2 id='sec-pass-to-app'> -<head>XML Processor Treatment of Logical Structure</head> -<p>When an XML processor encounters a start-tag, it must make -at least the following information available to the application: -<ulist> -<item> -<p>the element type's generic identifier</p> -</item> -<item> -<p>the names of attributes known to apply to this element type -(validating processors must make available names of all attributes -declared for the element type; non-validating processors must -make available at least the names of the attributes for which -values are specified. -</p> -</item> -</ulist> -</p> -</div2> ---> - -</div1> -<!-- &Entities; --> - -<div1 id="sec-physical-struct"> -<head>Physical Structures</head> - -<p><termdef id="dt-entity" term="Entity">An XML document may consist -of one or many storage units. These are called -<term>entities</term>; they all have <term>content</term> and are all -(except for the document entity, see below, and -the <termref def="dt-doctype">external DTD subset</termref>) -identified by <term>name</term>. -</termdef> -Each XML document has one entity -called the <termref def="dt-docent">document entity</termref>, which serves -as the starting point for the <termref def="dt-xml-proc">XML -processor</termref> and may contain the whole document.</p> -<p>Entities may be either parsed or unparsed. -<termdef id="dt-parsedent" term="Text Entity">A <term>parsed entity's</term> -contents are referred to as its -<termref def="dt-repltext">replacement text</termref>; -this <termref def="dt-text">text</termref> is considered an -integral part of the document.</termdef></p> - -<p><termdef id="dt-unparsed" term="Unparsed Entity">An -<term>unparsed entity</term> -is a resource whose contents may or may not be -<termref def="dt-text">text</termref>, and if text, may not be XML. -Each unparsed entity -has an associated <termref def="dt-notation">notation</termref>, 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.</termdef> -</p> -<p> -Parsed entities are invoked by name using entity references; -unparsed entities by name, given in the value of <kw>ENTITY</kw> -or <kw>ENTITIES</kw> -attributes.</p> -<p><termdef id="gen-entity" term="general entity"><term>General entities</term> -are entities for use within the document content. -In this specification, general entities are sometimes referred -to with the unqualified term <emph>entity</emph> when this leads -to no ambiguity.</termdef> -<termdef id="dt-PE" term="Parameter entity">Parameter entities -are parsed entities for use within the DTD.</termdef> -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> - -<div2 id="sec-references"> -<head>Character and Entity References</head> -<p><termdef id="dt-charref" term="Character Reference"> -A <term>character reference</term> refers to a specific character in the -ISO/IEC 10646 character set, for example one not directly accessible from -available input devices. -<scrap lang="ebnf"> -<head>Character Reference</head> -<prod id="NT-CharRef"><lhs>CharRef</lhs> -<rhs>'&#' [0-9]+ ';' </rhs> -<rhs>| '&hcro;' [0-9a-fA-F]+ ';'</rhs> -<wfc def="wf-Legalchar"/> -</prod> -</scrap> -<wfcnote id="wf-Legalchar"> -<head>Legal Character</head> -<p>Characters referred to using character references must -match the production for -<termref def="NT-Char">Char</termref>.</p> -</wfcnote> -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. -</termdef> -</p> -<p><termdef id="dt-entref" term="Entity Reference">An <term>entity -reference</term> refers to the content of a named entity.</termdef> -<termdef id="dt-GERef" term="General Entity Reference">References to -parsed general entities -use ampersand (<code>&</code>) and semicolon (<code>;</code>) as -delimiters.</termdef> -<termdef id="dt-PERef" term="Parameter-entity reference"> -<term>Parameter-entity references</term> use percent-sign (<code>%</code>) and -semicolon -(<code>;</code>) as delimiters.</termdef> -</p> -<scrap lang="ebnf"> -<head>Entity Reference</head> -<prod id="NT-Reference"><lhs>Reference</lhs> -<rhs><nt def="NT-EntityRef">EntityRef</nt> -| <nt def="NT-CharRef">CharRef</nt></rhs></prod> -<prod id="NT-EntityRef"><lhs>EntityRef</lhs> -<rhs>'&' <nt def="NT-Name">Name</nt> ';'</rhs> -<wfc def="wf-entdeclared"/> -<vc def="vc-entdeclared"/> -<wfc def="textent"/> -<wfc def="norecursion"/> -</prod> -<prod id="NT-PEReference"><lhs>PEReference</lhs> -<rhs>'%' <nt def="NT-Name">Name</nt> ';'</rhs> -<vc def="vc-entdeclared"/> -<wfc def="norecursion"/> -<wfc def="indtd"/> -</prod> -</scrap> - -<wfcnote id="wf-entdeclared"> -<head>Entity Declared</head> -<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>", -the <nt def="NT-Name">Name</nt> given in the entity reference must -<termref def="dt-match">match</termref> that in an -<titleref href="sec-entity-decl">entity declaration</titleref>, except that -well-formed documents need not declare -any of the following entities: &magicents;. -The declaration of a parameter entity must precede any reference to it. -Similarly, the declaration of a general entity must precede any -reference to it which appears in a default value in an attribute-list -declaration.</p> -<p>Note that if entities are declared in the external subset or in -external parameter entities, a non-validating processor is -<titleref href="include-if-valid">not obligated to</titleref> read -and process their declarations; for such documents, the rule that -an entity must be declared is a well-formedness constraint only -if <titleref href="sec-rmd">standalone='yes'</titleref>.</p> -</wfcnote> -<vcnote id="vc-entdeclared"> -<head>Entity Declared</head> -<p>In a document with an external subset or external parameter -entities with "<code>standalone='no'</code>", -the <nt def="NT-Name">Name</nt> given in the entity reference must <termref def="dt-match">match</termref> that in an -<titleref href="sec-entity-decl">entity declaration</titleref>. -For interoperability, valid documents should declare the entities -&magicents;, in the form -specified in <specref ref="sec-predefined-ent"/>. -The declaration of a parameter entity must precede any reference to it. -Similarly, the declaration of a general entity must precede any -reference to it which appears in a default value in an attribute-list -declaration.</p> -</vcnote> -<!-- FINAL EDIT: is this duplication too clumsy? --> -<wfcnote id="textent"> -<head>Parsed Entity</head> -<p> -An entity reference must not contain the name of an <termref def="dt-unparsed">unparsed entity</termref>. Unparsed entities may be referred -to only in <termref def="dt-attrval">attribute values</termref> declared to -be of type <kw>ENTITY</kw> or <kw>ENTITIES</kw>. -</p> -</wfcnote> -<wfcnote id="norecursion"> -<head>No Recursion</head> -<p> -A parsed entity must not contain a recursive reference to itself, -either directly or indirectly. -</p> -</wfcnote> -<wfcnote id="indtd"> -<head>In DTD</head> -<p> -Parameter-entity references may only appear in the -<termref def="dt-doctype">DTD</termref>. -</p> -</wfcnote> -<p>Examples of character and entity references: -<eg>Type <key>less-than</key> (&hcro;3C;) to save options. -This document was prepared on &docdate; and -is classified &security-level;.</eg></p> -<p>Example of a parameter-entity reference: -<eg><![CDATA[<!-- declare the parameter entity "ISOLat2"... --> -<!ENTITY % ISOLat2 - SYSTEM "http://www.xml.com/iso/isolat2-xml.entities" > -<!-- ... now reference it. --> -%ISOLat2;]]></eg></p> -</div2> - -<div2 id="sec-entity-decl"> -<head>Entity Declarations</head> - -<p><termdef id="dt-entdecl" term="entity declaration"> -Entities are declared thus: -<scrap lang="ebnf"> -<head>Entity Declaration</head> -<prodgroup pcw2="5" pcw4="18.5"> -<prod id="NT-EntityDecl"><lhs>EntityDecl</lhs> -<rhs><nt def="NT-GEDecl">GEDecl</nt><!--</rhs><com>General entities</com> -<rhs>--> | <nt def="NT-PEDecl">PEDecl</nt></rhs> -<!--<com>Parameter entities</com>--> -</prod> -<prod id="NT-GEDecl"><lhs>GEDecl</lhs> -<rhs>'<!ENTITY' <nt def="NT-S">S</nt> <nt def="NT-Name">Name</nt> -<nt def="NT-S">S</nt> <nt def="NT-EntityDef">EntityDef</nt> -<nt def="NT-S">S</nt>? '>'</rhs> -</prod> -<prod id="NT-PEDecl"><lhs>PEDecl</lhs> -<rhs>'<!ENTITY' <nt def="NT-S">S</nt> '%' <nt def="NT-S">S</nt> -<nt def="NT-Name">Name</nt> <nt def="NT-S">S</nt> -<nt def="NT-PEDef">PEDef</nt> <nt def="NT-S">S</nt>? '>'</rhs> -<!--<com>Parameter entities</com>--> -</prod> -<prod id="NT-EntityDef"><lhs>EntityDef</lhs> -<rhs><nt def="NT-EntityValue">EntityValue</nt> -<!--</rhs> -<rhs>-->| (<nt def="NT-ExternalID">ExternalID</nt> -<nt def="NT-NDataDecl">NDataDecl</nt>?)</rhs> -<!-- <nt def='NT-ExternalDef'>ExternalDef</nt></rhs> --> -</prod> -<!-- FINAL EDIT: what happened to WFs here? --> -<prod id="NT-PEDef"><lhs>PEDef</lhs> -<rhs><nt def="NT-EntityValue">EntityValue</nt> -| <nt def="NT-ExternalID">ExternalID</nt></rhs></prod> -</prodgroup> -</scrap> -The <nt def="NT-Name">Name</nt> identifies the entity in an -<termref def="dt-entref">entity reference</termref> or, in the case of an -unparsed entity, in the value of an <kw>ENTITY</kw> or <kw>ENTITIES</kw> -attribute. -If the same entity is declared more than once, the first declaration -encountered is binding; at user option, an XML processor may issue a -warning if entities are declared multiple times.</termdef> -</p> - -<div3 id="sec-internal-ent"> -<head>Internal Entities</head> - -<p><termdef id="dt-internent" term="Internal Entity Replacement Text">If -the entity definition is an -<nt def="NT-EntityValue">EntityValue</nt>, -the defined entity is called an <term>internal entity</term>. -There is no separate physical -storage object, and the content of the entity is given in the -declaration. </termdef> -Note that some processing of entity and character references in the -<termref def="dt-litentval">literal entity value</termref> may be required to -produce the correct <termref def="dt-repltext">replacement -text</termref>: see <specref ref="intern-replacement"/>. -</p> -<p>An internal entity is a <termref def="dt-parsedent">parsed -entity</termref>.</p> -<p>Example of an internal entity declaration: -<eg><!ENTITY Pub-Status "This is a pre-release of the - specification."></eg></p> -</div3> - -<div3 id="sec-external-ent"> -<head>External Entities</head> - -<p><termdef id="dt-extent" term="External Entity">If the entity is not -internal, it is an <term>external -entity</term>, declared as follows: -<scrap lang="ebnf"> -<head>External Entity Declaration</head> -<!-- -<prod id='NT-ExternalDef'><lhs>ExternalDef</lhs> -<rhs></prod> --> -<prod id="NT-ExternalID"><lhs>ExternalID</lhs> -<rhs>'SYSTEM' <nt def="NT-S">S</nt> -<nt def="NT-SystemLiteral">SystemLiteral</nt></rhs> -<rhs>| 'PUBLIC' <nt def="NT-S">S</nt> -<nt def="NT-PubidLiteral">PubidLiteral</nt> -<nt def="NT-S">S</nt> -<nt def="NT-SystemLiteral">SystemLiteral</nt> -</rhs> -</prod> -<prod id="NT-NDataDecl"><lhs>NDataDecl</lhs> -<rhs><nt def="NT-S">S</nt> 'NDATA' <nt def="NT-S">S</nt> -<nt def="NT-Name">Name</nt></rhs> -<vc def="not-declared"/></prod> -</scrap> -If the <nt def="NT-NDataDecl">NDataDecl</nt> is present, this is a -general <termref def="dt-unparsed">unparsed -entity</termref>; otherwise it is a parsed entity.</termdef></p> -<vcnote id="not-declared"> -<head>Notation Declared</head> -<p> -The <nt def="NT-Name">Name</nt> must match the declared name of a -<termref def="dt-notation">notation</termref>. -</p> -</vcnote> -<p><termdef id="dt-sysid" term="System Identifier">The -<nt def="NT-SystemLiteral">SystemLiteral</nt> -is called the entity's <term>system identifier</term>. It is a URI, -which may be used to retrieve the entity.</termdef> -Note that the hash mark (<code>#</code>) and fragment identifier -frequently used with URIs are not, formally, part of the URI itself; -an XML processor may signal an error if a fragment identifier is -given as 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. -A URI might thus be relative to the -<termref def="dt-docent">document entity</termref>, to the entity -containing the <termref def="dt-doctype">external DTD subset</termref>, -or to some other <termref def="dt-extent">external parameter entity</termref>. -</p> -<p>An XML processor should handle a non-ASCII character in a URI by -representing the character in UTF-8 as one or more bytes, and then -escaping these bytes with the URI escaping mechanism (i.e., by -converting each byte to %HH, where HH is the hexadecimal notation of the -byte value).</p> -<p><termdef id="dt-pubid" term="Public identifier"> -In addition to a system identifier, an external identifier may -include a <term>public identifier</term>.</termdef> -An XML processor attempting to retrieve the entity's content may use the public -identifier to try to generate an alternative URI. If the processor -is unable to do so, it must use the URI specified in the system -literal. Before a match is attempted, all strings -of white space in the public identifier must be normalized to single space characters (#x20), -and leading and trailing white space must be removed.</p> -<p>Examples of external entity declarations: -<eg><!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 ></eg></p> -</div3> - -</div2> - -<div2 id="TextEntities"> -<head>Parsed Entities</head> -<div3 id="sec-TextDecl"> -<head>The Text Declaration</head> -<p>External parsed entities may each begin with a <term>text -declaration</term>. -<scrap lang="ebnf"> -<head>Text Declaration</head> -<prodgroup pcw4="12.5" pcw5="13"> -<prod id="NT-TextDecl"><lhs>TextDecl</lhs> -<rhs>&xmlpio; -<nt def="NT-VersionInfo">VersionInfo</nt>? -<nt def="NT-EncodingDecl">EncodingDecl</nt> -<nt def="NT-S">S</nt>? &pic;</rhs> -</prod> -</prodgroup> -</scrap> -</p> -<p>The text declaration must be provided literally, not -by reference to a parsed entity. -No text declaration may appear at any position other than the beginning of -an external parsed entity.</p> -</div3> -<div3 id="wf-entities"> -<head>Well-Formed Parsed Entities</head> -<p>The document entity is well-formed if it matches the production labeled -<nt def="NT-document">document</nt>. -An external general -parsed entity is well-formed if it matches the production labeled -<nt def="NT-extParsedEnt">extParsedEnt</nt>. -An external parameter -entity is well-formed if it matches the production labeled -<nt def="NT-extPE">extPE</nt>. -<scrap lang="ebnf"> -<head>Well-Formed External Parsed Entity</head> -<prod id="NT-extParsedEnt"><lhs>extParsedEnt</lhs> -<rhs><nt def="NT-TextDecl">TextDecl</nt>? -<nt def="NT-content">content</nt></rhs> -</prod> -<prod id="NT-extPE"><lhs>extPE</lhs> -<rhs><nt def="NT-TextDecl">TextDecl</nt>? -<nt def="NT-extSubsetDecl">extSubsetDecl</nt></rhs> -</prod> -</scrap> -An internal general parsed entity is well-formed if its replacement text -matches the production labeled -<nt def="NT-content">content</nt>. -All internal parameter entities are well-formed by definition. -</p> -<p>A consequence of well-formedness in entities is that the logical -and physical structures in an XML document are properly nested; no -<termref def="dt-stag">start-tag</termref>, -<termref def="dt-etag">end-tag</termref>, -<termref def="dt-empty">empty-element tag</termref>, -<termref def="dt-element">element</termref>, -<termref def="dt-comment">comment</termref>, -<termref def="dt-pi">processing instruction</termref>, -<termref def="dt-charref">character -reference</termref>, or -<termref def="dt-entref">entity reference</termref> -can begin in one entity and end in another.</p> -</div3> -<div3 id="charencoding"> -<head>Character Encoding in Entities</head> - -<p>Each external parsed entity in an XML document may use a different -encoding for its characters. All XML processors must be able to read -entities in either UTF-8 or UTF-16. - -</p> -<p>Entities encoded in UTF-16 must -begin with the Byte Order Mark described by ISO/IEC 10646 Annex E and -Unicode Appendix B (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 must 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. -Parsed entities which are stored in an encoding other than -UTF-8 or UTF-16 must begin with a <titleref href="TextDecl">text -declaration</titleref> containing an encoding declaration: -<scrap lang="ebnf"> -<head>Encoding Declaration</head> -<prod id="NT-EncodingDecl"><lhs>EncodingDecl</lhs> -<rhs><nt def="NT-S">S</nt> -'encoding' <nt def="NT-Eq">Eq</nt> -('"' <nt def="NT-EncName">EncName</nt> '"' | -"'" <nt def="NT-EncName">EncName</nt> "'" ) -</rhs> -</prod> -<prod id="NT-EncName"><lhs>EncName</lhs> -<rhs>[A-Za-z] ([A-Za-z0-9._] | '-')*</rhs> -<com>Encoding name contains only Latin characters</com> -</prod> -</scrap> -In the <termref def="dt-docent">document entity</termref>, the encoding -declaration is part of the <termref def="dt-xmldecl">XML declaration</termref>. -The <nt def="NT-EncName">EncName</nt> is the name of the encoding used. -</p> -<!-- FINAL EDIT: check name of IANA and charset names --> -<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>" should 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-9</code>" should 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>" -should be used for the various encoded forms of JIS X-0208-1997. XML -processors may recognize other encodings; it is recommended that -character encodings registered (as <emph>charset</emph>s) -with the Internet Assigned Numbers -Authority <bibref ref="IANA"/>, other than those just listed, should be -referred to -using their registered names. -Note that these registered names are defined to be -case-insensitive, so processors wishing to match against them -should do so in a case-insensitive -way.</p> -<p>In the absence of information provided by an external -transport protocol (e.g. HTTP or MIME), -it is an <termref def="dt-error">error</termref> for an entity including -an encoding declaration to be presented to the XML processor -in an encoding other than that named in the declaration, -for an encoding declaration to occur other than at the beginning -of an external entity, 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 <termref def="dt-fatal">fatal error</termref> when an XML processor -encounters an entity with an encoding that it is unable to process.</p> -<p>Examples of encoding declarations: -<eg><?xml encoding='UTF-8'?> -<?xml encoding='EUC-JP'?></eg></p> -</div3> -</div2> -<div2 id="entproc"> -<head>XML Processor Treatment of Entities and References</head> -<p>The table below summarizes the contexts in which character references, -entity references, and invocations of unparsed entities might appear and the -required behavior of an <termref def="dt-xml-proc">XML processor</termref> in -each case. -The labels in the leftmost column describe the recognition context: -<glist> -<gitem><label>Reference in Content</label> -<def><p>as a reference -anywhere after the <termref def="dt-stag">start-tag</termref> and -before the <termref def="dt-etag">end-tag</termref> of an element; corresponds -to the nonterminal <nt def="NT-content">content</nt>.</p></def> -</gitem> -<gitem> -<label>Reference in Attribute Value</label> -<def><p>as a reference within either the value of an attribute in a -<termref def="dt-stag">start-tag</termref>, or a default -value in an <termref def="dt-attdecl">attribute declaration</termref>; -corresponds to the nonterminal -<nt def="NT-AttValue">AttValue</nt>.</p></def></gitem> -<gitem> -<label>Occurs as Attribute Value</label> -<def><p>as a <nt def="NT-Name">Name</nt>, not a reference, appearing either as -the value of an -attribute which has been declared as type <kw>ENTITY</kw>, or as one of -the space-separated tokens in the value of an attribute which has been -declared as type <kw>ENTITIES</kw>.</p> -</def></gitem> -<gitem><label>Reference in Entity Value</label> -<def><p>as a reference -within a parameter or internal entity's -<termref def="dt-litentval">literal entity value</termref> in -the entity's declaration; corresponds to the nonterminal -<nt def="NT-EntityValue">EntityValue</nt>.</p></def></gitem> -<gitem><label>Reference in DTD</label> -<def><p>as a reference within either the internal or external subsets of the -<termref def="dt-doctype">DTD</termref>, but outside -of an <nt def="NT-EntityValue">EntityValue</nt> or -<nt def="NT-AttValue">AttValue</nt>.</p></def> -</gitem> -</glist></p> -<htable border="1" cellpadding="7" align="center"> -<htbody> -<tr><td bgcolor="&cellback;" rowspan="2" colspan="1"/> -<td bgcolor="&cellback;" align="center" valign="bottom" colspan="4">Entity Type</td> -<td bgcolor="&cellback;" rowspan="2" align="center">Character</td> -</tr> -<tr align="center" valign="bottom"> -<td bgcolor="&cellback;">Parameter</td> -<td bgcolor="&cellback;">Internal -General</td> -<td bgcolor="&cellback;">External Parsed -General</td> -<td bgcolor="&cellback;">Unparsed</td> -</tr> -<tr align="center" valign="middle"> - -<td bgcolor="&cellback;" align="right">Reference -in Content</td> -<td bgcolor="&cellback;"><titleref href="not-recognized">Not recognized</titleref></td> -<td bgcolor="&cellback;"><titleref href="included">Included</titleref></td> -<td bgcolor="&cellback;"><titleref href="include-if-valid">Included if validating</titleref></td> -<td bgcolor="&cellback;"><titleref href="forbidden">Forbidden</titleref></td> -<td bgcolor="&cellback;"><titleref href="included">Included</titleref></td> -</tr> -<tr align="center" valign="middle"> -<td bgcolor="&cellback;" align="right">Reference -in Attribute Value</td> -<td bgcolor="&cellback;"><titleref href="not-recognized">Not recognized</titleref></td> -<td bgcolor="&cellback;"><titleref href="inliteral">Included in literal</titleref></td> -<td bgcolor="&cellback;"><titleref href="forbidden">Forbidden</titleref></td> -<td bgcolor="&cellback;"><titleref href="forbidden">Forbidden</titleref></td> -<td bgcolor="&cellback;"><titleref href="included">Included</titleref></td> -</tr> -<tr align="center" valign="middle"> -<td bgcolor="&cellback;" align="right">Occurs as -Attribute Value</td> -<td bgcolor="&cellback;"><titleref href="not-recognized">Not recognized</titleref></td> -<td bgcolor="&cellback;"><titleref href="not-recognized">Forbidden</titleref></td> -<td bgcolor="&cellback;"><titleref href="not-recognized">Forbidden</titleref></td> -<td bgcolor="&cellback;"><titleref href="notify">Notify</titleref></td> -<td bgcolor="&cellback;"><titleref href="not recognized">Not recognized</titleref></td> -</tr> -<tr align="center" valign="middle"> -<td bgcolor="&cellback;" align="right">Reference -in EntityValue</td> -<td bgcolor="&cellback;"><titleref href="inliteral">Included in literal</titleref></td> -<td bgcolor="&cellback;"><titleref href="bypass">Bypassed</titleref></td> -<td bgcolor="&cellback;"><titleref href="bypass">Bypassed</titleref></td> -<td bgcolor="&cellback;"><titleref href="forbidden">Forbidden</titleref></td> -<td bgcolor="&cellback;"><titleref href="included">Included</titleref></td> -</tr> -<tr align="center" valign="middle"> -<td bgcolor="&cellback;" align="right">Reference -in DTD</td> -<td bgcolor="&cellback;"><titleref href="as-PE">Included as PE</titleref></td> -<td bgcolor="&cellback;"><titleref href="forbidden">Forbidden</titleref></td> -<td bgcolor="&cellback;"><titleref href="forbidden">Forbidden</titleref></td> -<td bgcolor="&cellback;"><titleref href="forbidden">Forbidden</titleref></td> -<td bgcolor="&cellback;"><titleref href="forbidden">Forbidden</titleref></td> -</tr> -</htbody> -</htable> -<div3 id="not-recognized"> -<head>Not Recognized</head> -<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 <nt def="NT-content">content</nt>. -Similarly, the names of unparsed entities are not recognized except -when they appear in the value of an appropriately declared attribute. -</p> -</div3> -<div3 id="included"> -<head>Included</head> -<p><termdef id="dt-include" term="Include">An entity is -<term>included</term> when its -<termref def="dt-repltext">replacement text</termref> 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 may contain both -<termref def="dt-chardata">character data</termref> -and (except for parameter entities) <termref def="dt-markup">markup</termref>, -which must be recognized in -the usual way, except that the replacement text of entities used to escape -markup delimiters (the entities &magicents;) is always treated as -data. (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 <term>included</term> when the indicated -character is processed in place of the reference itself. -</termdef></p> -</div3> -<div3 id="include-if-valid"> -<head>Included If Validating</head> -<p>When an XML processor recognizes a reference to a parsed entity, in order -to <termref def="dt-valid">validate</termref> -the document, the processor must -<termref def="dt-include">include</termref> its -replacement text. -If the entity is external, and the processor is not -attempting to validate the XML document, the -processor <termref def="dt-may">may</termref>, but need not, -include the entity's replacement text. -If a non-validating parser does not include the replacement text, -it must 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> -</div3> -<div3 id="forbidden"> -<head>Forbidden</head> -<p>The following are forbidden, and constitute -<termref def="dt-fatal">fatal</termref> errors: -<ulist> -<item><p>the appearance of a reference to an -<termref def="dt-unparsed">unparsed entity</termref>. -</p></item> -<item><p>the appearance of any character or general-entity reference in the -DTD except within an <nt def="NT-EntityValue">EntityValue</nt> or -<nt def="NT-AttValue">AttValue</nt>.</p></item> -<item><p>a reference to an external entity in an attribute value.</p> -</item> -</ulist> -</p> -</div3> -<div3 id="inliteral"> -<head>Included in Literal</head> -<p>When an <termref def="dt-entref">entity reference</termref> appears in an -attribute value, or a parameter entity reference appears in a literal entity -value, its <termref def="dt-repltext">replacement text</termref> is -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 -is always treated as a normal data character and will not terminate the -literal. -For example, this is well-formed: -<eg><![CDATA[<!ENTITY % YN '"Yes"' > -<!ENTITY WhatHeSaid "He said &YN;" >]]></eg> -while this is not: -<eg><!ENTITY EndAttr "27'" > -<element attribute='a-&EndAttr;></eg> -</p></div3> -<div3 id="notify"> -<head>Notify</head> -<p>When the name of an <termref def="dt-unparsed">unparsed -entity</termref> appears as a token in the -value of an attribute of declared type <kw>ENTITY</kw> or <kw>ENTITIES</kw>, -a validating processor must inform the -application of the <termref def="dt-sysid">system</termref> -and <termref def="dt-pubid">public</termref> (if any) -identifiers for both the entity and its associated -<termref def="dt-notation">notation</termref>.</p> -</div3> -<div3 id="bypass"> -<head>Bypassed</head> -<p>When a general entity reference appears in the -<nt def="NT-EntityValue">EntityValue</nt> in an entity declaration, -it is bypassed and left as is.</p> -</div3> -<div3 id="as-PE"> -<head>Included as PE</head> -<p>Just as with external parsed entities, parameter entities -need only be <titleref href="include-if-valid">included if -validating</titleref>. -When a parameter-entity reference is recognized in the DTD -and included, its -<termref def="dt-repltext">replacement -text</termref> is 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. -</p> -</div3> - -</div2> -<div2 id="intern-replacement"> -<head>Construction of Internal Entity Replacement Text</head> -<p>In discussing the treatment -of internal entities, it is -useful to distinguish two forms of the entity's value. -<termdef id="dt-litentval" term="Literal Entity Value">The <term>literal -entity value</term> is the quoted string actually -present in the entity declaration, corresponding to the -non-terminal <nt def="NT-EntityValue">EntityValue</nt>.</termdef> -<termdef id="dt-repltext" term="Replacement Text">The <term>replacement -text</term> is the content of the entity, after -replacement of character references and parameter-entity -references. -</termdef></p> - -<p>The literal entity value -as given in an internal entity declaration -(<nt def="NT-EntityValue">EntityValue</nt>) may contain character, -parameter-entity, and general-entity references. -Such references must be contained entirely within the -literal entity value. -The actual replacement text that is -<termref def="dt-include">included</termref> as described above -must contain the <emph>replacement text</emph> of any -parameter entities referred to, and must contain the character -referred to, in place of any character references in the -literal entity value; however, -general-entity references must be left as-is, unexpanded. -For example, given the following declarations: - -<eg><![CDATA[<!ENTITY % pub "Éditions Gallimard" > -<!ENTITY rights "All rights reserved" > -<!ENTITY book "La Peste: Albert Camus, -© 1947 %pub;. &rights;" >]]></eg> -then the replacement text for the entity "<code>book</code>" is: -<eg>La Peste: Albert Camus, -© 1947 Éditions Gallimard. &rights;</eg> -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 -<specref ref="sec-entexpand"/>. -</p> - -</div2> -<div2 id="sec-predefined-ent"> -<head>Predefined Entities</head> -<p><termdef id="dt-escape" term="escape">Entity and character -references can both be used to <term>escape</term> the left angle bracket, -ampersand, and other delimiters. A set of general entities -(&magicents;) is specified for this purpose. -Numeric character references may also be used; they are -expanded immediately when recognized and must be treated as -character data, so the numeric character references -"<code>&#60;</code>" and "<code>&#38;</code>" may be used to -escape <code><</code> and <code>&</code> when they occur -in character data.</termdef></p> -<p>All XML processors must recognize these entities whether they -are declared or not. -<termref def="dt-interop">For interoperability</termref>, -valid XML documents should declare these -entities, like any others, before using them. -If the entities in question are declared, they must be declared -as internal entities whose replacement text is the single -character being escaped or a character reference to -that character, as shown below. -<eg><![CDATA[<!ENTITY lt "&#60;"> -<!ENTITY gt ">"> -<!ENTITY amp "&#38;"> -<!ENTITY apos "'"> -<!ENTITY quot """> -]]></eg> -Note that the <code><</code> and <code>&</code> characters -in the declarations of "<code>lt</code>" and "<code>amp</code>" -are doubly escaped to meet the requirement that entity replacement -be well-formed. -</p> -</div2> - -<div2 id="Notations"> -<head>Notation Declarations</head> - -<p><termdef id="dt-notation" term="Notation"><term>Notations</term> identify by -name the format of <termref def="dt-extent">unparsed -entities</termref>, the -format of elements which bear a notation attribute, -or the application to which -a <termref def="dt-pi">processing instruction</termref> is -addressed.</termdef></p> -<p><termdef id="dt-notdecl" term="Notation Declaration"> -<term>Notation declarations</term> -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. -<scrap lang="ebnf"> -<head>Notation Declarations</head> -<prod id="NT-NotationDecl"><lhs>NotationDecl</lhs> -<rhs>'<!NOTATION' <nt def="NT-S">S</nt> <nt def="NT-Name">Name</nt> -<nt def="NT-S">S</nt> -(<nt def="NT-ExternalID">ExternalID</nt> | -<nt def="NT-PublicID">PublicID</nt>) -<nt def="NT-S">S</nt>? '>'</rhs></prod> -<prod id="NT-PublicID"><lhs>PublicID</lhs> -<rhs>'PUBLIC' <nt def="NT-S">S</nt> -<nt def="NT-PubidLiteral">PubidLiteral</nt> -</rhs></prod> -</scrap> -</termdef></p> -<p>XML processors must 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 may -additionally resolve the external identifier into the -<termref def="dt-sysid">system identifier</termref>, -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> -</div2> - - -<div2 id="sec-doc-entity"> -<head>Document Entity</head> - -<p><termdef id="dt-docent" term="Document Entity">The <term>document -entity</term> serves as the root of the entity -tree and a starting-point for an <termref def="dt-xml-proc">XML -processor</termref>.</termdef> -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> -</div2> - - -</div1> -<!-- &Conformance; --> - -<div1 id="sec-conformance"> -<head>Conformance</head> - -<div2 id="proc-types"> -<head>Validating and Non-Validating Processors</head> -<p>Conforming <termref def="dt-xml-proc">XML processors</termref> fall into two -classes: validating and non-validating.</p> -<p>Validating and non-validating processors alike must report -violations of this specification's well-formedness constraints -in the content of the -<termref def="dt-docent">document entity</termref> and any -other <termref def="dt-parsedent">parsed entities</termref> that -they read.</p> -<p><termdef id="dt-validating" term="Validating Processor"> -<term>Validating processors</term> must report -violations of the constraints expressed by the declarations in the -<termref def="dt-doctype">DTD</termref>, and -failures to fulfill the validity constraints given -in this specification. -</termdef> -To accomplish this, validating XML processors must read and process the entire -DTD and all external parsed entities referenced in the document. -</p> -<p>Non-validating processors are required to check only the -<termref def="dt-docent">document entity</termref>, including -the entire internal DTD subset, for well-formedness. -<termdef id="dt-use-mdecl" term="Process Declarations"> -While they are not required to check the document for validity, -they are required to -<term>process</term> 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 <emph>not</emph> read; that is to -say, they must -use the information in those declarations to -<titleref href="AVNormalize">normalize</titleref> attribute values, -<titleref href="included">include</titleref> the replacement text of -internal entities, and supply -<titleref href="sec-attr-defaults">default attribute values</titleref>. -</termdef> -They must not <termref def="dt-use-mdecl">process</termref> -<termref def="dt-entdecl">entity declarations</termref> or -<termref def="dt-attdecl">attribute-list declarations</termref> -encountered after a reference to a parameter entity that is not -read, since the entity may have contained overriding declarations. -</p> -</div2> -<div2 id="safe-behavior"> -<head>Using XML Processors</head> -<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: -<ulist> -<item><p>Certain well-formedness errors, specifically those that require -reading external entities, may not be detected by a non-validating processor. -Examples include the constraints entitled -<titleref href="wf-entdeclared">Entity Declared</titleref>, -<titleref href="wf-textent">Parsed Entity</titleref>, and -<titleref href="wf-norecursion">No Recursion</titleref>, as well -as some of the cases described as -<titleref href="forbidden">forbidden</titleref> in -<specref ref="entproc"/>.</p></item> -<item><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 may not -<titleref href="AVNormalize">normalize</titleref> attribute values, -<titleref href="included">include</titleref> the replacement text of -internal entities, or supply -<titleref href="sec-attr-defaults">default attribute values</titleref>, -where doing so depends on having read declarations in -external or parameter entities.</p></item> -</ulist> -</p> -<p>For maximum reliability in interoperating between different XML -processors, applications which use non-validating processors should not -rely on any behaviors not required of such processors. -Applications which require facilities such as the use of default -attributes or internal entities which are declared in external -entities should use validating XML processors.</p> -</div2> -</div1> - -<div1 id="sec-notation"> -<head>Notation</head> - -<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 -<eg>symbol ::= expression</eg></p> -<p>Symbols are written with an initial capital letter if they are -defined by a regular expression, or with an initial lower case letter -otherwise. -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: -<glist> -<gitem> -<label><code>#xN</code></label> -<def><p>where <code>N</code> is a hexadecimal integer, the -expression matches the character in ISO/IEC 10646 whose canonical -(UCS-4) -code value, when interpreted as an unsigned binary number, has -the value indicated. The number of leading zeros in the -<code>#xN</code> form is insignificant; the number of leading -zeros in the corresponding code value -is governed by the character -encoding in use and is not significant for XML.</p></def> -</gitem> -<gitem> -<label><code>[a-zA-Z]</code>, <code>[#xN-#xN]</code></label> -<def><p>matches any <termref def="dt-character">character</termref> -with a value in the range(s) indicated (inclusive).</p></def> -</gitem> -<gitem> -<label><code>[^a-z]</code>, <code>[^#xN-#xN]</code></label> -<def><p>matches any <termref def="dt-character">character</termref> -with a value <emph>outside</emph> the -range indicated.</p></def> -</gitem> -<gitem> -<label><code>[^abc]</code>, <code>[^#xN#xN#xN]</code></label> -<def><p>matches any <termref def="dt-character">character</termref> -with a value not among the characters given.</p></def> -</gitem> -<gitem> -<label><code>"string"</code></label> -<def><p>matches a literal string <termref def="dt-match">matching</termref> -that given inside the double quotes.</p></def> -</gitem> -<gitem> -<label><code>'string'</code></label> -<def><p>matches a literal string <termref def="dt-match">matching</termref> -that given inside the single quotes.</p></def> -</gitem> -</glist> -These symbols may be combined to match more complex patterns as follows, -where <code>A</code> and <code>B</code> represent simple expressions: -<glist> -<gitem> -<label>(<code>expression</code>)</label> -<def><p><code>expression</code> is treated as a unit -and may be combined as described in this list.</p></def> -</gitem> -<gitem> -<label><code>A?</code></label> -<def><p>matches <code>A</code> or nothing; optional <code>A</code>.</p></def> -</gitem> -<gitem> -<label><code>A B</code></label> -<def><p>matches <code>A</code> followed by <code>B</code>.</p></def> -</gitem> -<gitem> -<label><code>A | B</code></label> -<def><p>matches <code>A</code> or <code>B</code> but not both.</p></def> -</gitem> -<gitem> -<label><code>A - B</code></label> -<def><p>matches any string that matches <code>A</code> but does not match -<code>B</code>. -</p></def> -</gitem> -<gitem> -<label><code>A+</code></label> -<def><p>matches one or more occurrences of <code>A</code>.</p></def> -</gitem> -<gitem> -<label><code>A*</code></label> -<def><p>matches zero or more occurrences of <code>A</code>.</p></def> -</gitem> - -</glist> -Other notations used in the productions are: -<glist> -<gitem> -<label><code>/* ... */</code></label> -<def><p>comment.</p></def> -</gitem> -<gitem> -<label><code>[ wfc: ... ]</code></label> -<def><p>well-formedness constraint; this identifies by name a -constraint on -<termref def="dt-wellformed">well-formed</termref> documents -associated with a production.</p></def> -</gitem> -<gitem> -<label><code>[ vc: ... ]</code></label> -<def><p>validity constraint; this identifies by name a constraint on -<termref def="dt-valid">valid</termref> documents associated with -a production.</p></def> -</gitem> -</glist> -</p></div1> - -</body> -<back> -<!-- &SGML; --> - - -<!-- &Biblio; --> -<div1 id="sec-bibliography"> - -<head>References</head> -<div2 id="sec-existing-stds"> -<head>Normative References</head> - -<blist> -<bibl id="IANA" key="IANA"> -(Internet Assigned Numbers Authority) <emph>Official Names for -Character Sets</emph>, -ed. Keld Simonsen et al. -See <loc href="ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets">ftp://ftp.isi.edu/in-notes/iana/assignments/character-sets</loc>. -</bibl> - -<bibl id="RFC1766" key="IETF RFC 1766"> -IETF (Internet Engineering Task Force). -<emph>RFC 1766: Tags for the Identification of Languages</emph>, -ed. H. Alvestrand. -1995. -</bibl> - -<bibl id="ISO639" key="ISO 639"> -(International Organization for Standardization). -<emph>ISO 639:1988 (E). -Code for the representation of names of languages.</emph> -[Geneva]: International Organization for -Standardization, 1988.</bibl> - -<bibl id="ISO3166" key="ISO 3166"> -(International Organization for Standardization). -<emph>ISO 3166-1:1997 (E). -Codes for the representation of names of countries and their subdivisions -— Part 1: Country codes</emph> -[Geneva]: International Organization for -Standardization, 1997.</bibl> - -<bibl id="ISO10646" key="ISO/IEC 10646">ISO -(International Organization for Standardization). -<emph>ISO/IEC 10646-1993 (E). Information technology — Universal -Multiple-Octet Coded Character Set (UCS) — Part 1: -Architecture and Basic Multilingual Plane.</emph> -[Geneva]: International Organization for -Standardization, 1993 (plus amendments AM 1 through AM 7). -</bibl> - -<bibl id="Unicode" key="Unicode">The Unicode Consortium. -<emph>The Unicode Standard, Version 2.0.</emph> -Reading, Mass.: Addison-Wesley Developers Press, 1996.</bibl> - -</blist> - -</div2> - -<div2><head>Other References</head> - -<blist> - -<bibl id="Aho" key="Aho/Ullman">Aho, Alfred V., -Ravi Sethi, and Jeffrey D. Ullman. -<emph>Compilers: Principles, Techniques, and Tools</emph>. -Reading: Addison-Wesley, 1986, rpt. corr. 1988.</bibl> - -<bibl id="Berners-Lee" xml-link="simple" key="Berners-Lee et al."> -Berners-Lee, T., R. Fielding, and L. Masinter. -<emph>Uniform Resource Identifiers (URI): Generic Syntax and -Semantics</emph>. -1997. -(Work in progress; see updates to RFC1738.)</bibl> - -<bibl id="ABK" key="Brüggemann-Klein">Brüggemann-Klein, Anne. -<emph>Regular Expressions into Finite Automata</emph>. -Extended abstract in I. Simon, Hrsg., LATIN 1992, -S. 97-98. Springer-Verlag, Berlin 1992. -Full Version in Theoretical Computer Science 120: 197-213, 1993. - -</bibl> - -<bibl id="ABKDW" key="Brüggemann-Klein and Wood">Brüggemann-Klein, Anne, -and Derick Wood. -<emph>Deterministic Regular Languages</emph>. -Universität Freiburg, Institut für Informatik, -Bericht 38, Oktober 1991. -</bibl> - -<bibl id="Clark" key="Clark">James Clark. -Comparison of SGML and XML. See -<loc href="http://www.w3.org/TR/NOTE-sgml-xml-971215">http://www.w3.org/TR/NOTE-sgml-xml-971215</loc>. -</bibl> -<bibl id="RFC1738" xml-link="simple" key="IETF RFC1738"> -IETF (Internet Engineering Task Force). -<emph>RFC 1738: Uniform Resource Locators (URL)</emph>, -ed. T. Berners-Lee, L. Masinter, M. McCahill. -1994. -</bibl> - -<bibl id="RFC1808" xml-link="simple" key="IETF RFC1808"> -IETF (Internet Engineering Task Force). -<emph>RFC 1808: Relative Uniform Resource Locators</emph>, -ed. R. Fielding. -1995. -</bibl> - -<bibl id="RFC2141" xml-link="simple" key="IETF RFC2141"> -IETF (Internet Engineering Task Force). -<emph>RFC 2141: URN Syntax</emph>, -ed. R. Moats. -1997. -</bibl> - -<bibl id="ISO8879" key="ISO 8879">ISO -(International Organization for Standardization). -<emph>ISO 8879:1986(E). Information processing — Text and Office -Systems — Standard Generalized Markup Language (SGML).</emph> First -edition — 1986-10-15. [Geneva]: International Organization for -Standardization, 1986. -</bibl> - - -<bibl id="ISO10744" key="ISO/IEC 10744">ISO -(International Organization for Standardization). -<emph>ISO/IEC 10744-1992 (E). Information technology — -Hypermedia/Time-based Structuring Language (HyTime). -</emph> -[Geneva]: International Organization for -Standardization, 1992. -<emph>Extended Facilities Annexe.</emph> -[Geneva]: International Organization for -Standardization, 1996. -</bibl> - - - -</blist> -</div2> -</div1> -<div1 id="CharClasses"> -<head>Character Classes</head> -<p>Following the characteristics defined in the Unicode standard, -characters are classed as base characters (among others, these -contain the alphabetic characters of the Latin alphabet, without -diacritics), ideographic characters, and combining characters (among -others, this class contains most diacritics); these classes combine -to form the class of letters. Digits and extenders are -also distinguished. -<scrap lang="ebnf" id="CHARACTERS"> -<head>Characters</head> -<prodgroup pcw3="3" pcw4="15"> -<prod id="NT-Letter"><lhs>Letter</lhs> -<rhs><nt def="NT-BaseChar">BaseChar</nt> -| <nt def="NT-Ideographic">Ideographic</nt></rhs> </prod> -<prod id="NT-BaseChar"><lhs>BaseChar</lhs> -<rhs>[#x0041-#x005A] -| [#x0061-#x007A] -| [#x00C0-#x00D6] -| [#x00D8-#x00F6] -| [#x00F8-#x00FF] -| [#x0100-#x0131] -| [#x0134-#x013E] -| [#x0141-#x0148] -| [#x014A-#x017E] -| [#x0180-#x01C3] -| [#x01CD-#x01F0] -| [#x01F4-#x01F5] -| [#x01FA-#x0217] -| [#x0250-#x02A8] -| [#x02BB-#x02C1] -| #x0386 -| [#x0388-#x038A] -| #x038C -| [#x038E-#x03A1] -| [#x03A3-#x03CE] -| [#x03D0-#x03D6] -| #x03DA -| #x03DC -| #x03DE -| #x03E0 -| [#x03E2-#x03F3] -| [#x0401-#x040C] -| [#x040E-#x044F] -| [#x0451-#x045C] -| [#x045E-#x0481] -| [#x0490-#x04C4] -| [#x04C7-#x04C8] -| [#x04CB-#x04CC] -| [#x04D0-#x04EB] -| [#x04EE-#x04F5] -| [#x04F8-#x04F9] -| [#x0531-#x0556] -| #x0559 -| [#x0561-#x0586] -| [#x05D0-#x05EA] -| [#x05F0-#x05F2] -| [#x0621-#x063A] -| [#x0641-#x064A] -| [#x0671-#x06B7] -| [#x06BA-#x06BE] -| [#x06C0-#x06CE] -| [#x06D0-#x06D3] -| #x06D5 -| [#x06E5-#x06E6] -| [#x0905-#x0939] -| #x093D -| [#x0958-#x0961] -| [#x0985-#x098C] -| [#x098F-#x0990] -| [#x0993-#x09A8] -| [#x09AA-#x09B0] -| #x09B2 -| [#x09B6-#x09B9] -| [#x09DC-#x09DD] -| [#x09DF-#x09E1] -| [#x09F0-#x09F1] -| [#x0A05-#x0A0A] -| [#x0A0F-#x0A10] -| [#x0A13-#x0A28] -| [#x0A2A-#x0A30] -| [#x0A32-#x0A33] -| [#x0A35-#x0A36] -| [#x0A38-#x0A39] -| [#x0A59-#x0A5C] -| #x0A5E -| [#x0A72-#x0A74] -| [#x0A85-#x0A8B] -| #x0A8D -| [#x0A8F-#x0A91] -| [#x0A93-#x0AA8] -| [#x0AAA-#x0AB0] -| [#x0AB2-#x0AB3] -| [#x0AB5-#x0AB9] -| #x0ABD -| #x0AE0 -| [#x0B05-#x0B0C] -| [#x0B0F-#x0B10] -| [#x0B13-#x0B28] -| [#x0B2A-#x0B30] -| [#x0B32-#x0B33] -| [#x0B36-#x0B39] -| #x0B3D -| [#x0B5C-#x0B5D] -| [#x0B5F-#x0B61] -| [#x0B85-#x0B8A] -| [#x0B8E-#x0B90] -| [#x0B92-#x0B95] -| [#x0B99-#x0B9A] -| #x0B9C -| [#x0B9E-#x0B9F] -| [#x0BA3-#x0BA4] -| [#x0BA8-#x0BAA] -| [#x0BAE-#x0BB5] -| [#x0BB7-#x0BB9] -| [#x0C05-#x0C0C] -| [#x0C0E-#x0C10] -| [#x0C12-#x0C28] -| [#x0C2A-#x0C33] -| [#x0C35-#x0C39] -| [#x0C60-#x0C61] -| [#x0C85-#x0C8C] -| [#x0C8E-#x0C90] -| [#x0C92-#x0CA8] -| [#x0CAA-#x0CB3] -| [#x0CB5-#x0CB9] -| #x0CDE -| [#x0CE0-#x0CE1] -| [#x0D05-#x0D0C] -| [#x0D0E-#x0D10] -| [#x0D12-#x0D28] -| [#x0D2A-#x0D39] -| [#x0D60-#x0D61] -| [#x0E01-#x0E2E] -| #x0E30 -| [#x0E32-#x0E33] -| [#x0E40-#x0E45] -| [#x0E81-#x0E82] -| #x0E84 -| [#x0E87-#x0E88] -| #x0E8A -| #x0E8D -| [#x0E94-#x0E97] -| [#x0E99-#x0E9F] -| [#x0EA1-#x0EA3] -| #x0EA5 -| #x0EA7 -| [#x0EAA-#x0EAB] -| [#x0EAD-#x0EAE] -| #x0EB0 -| [#x0EB2-#x0EB3] -| #x0EBD -| [#x0EC0-#x0EC4] -| [#x0F40-#x0F47] -| [#x0F49-#x0F69] -| [#x10A0-#x10C5] -| [#x10D0-#x10F6] -| #x1100 -| [#x1102-#x1103] -| [#x1105-#x1107] -| #x1109 -| [#x110B-#x110C] -| [#x110E-#x1112] -| #x113C -| #x113E -| #x1140 -| #x114C -| #x114E -| #x1150 -| [#x1154-#x1155] -| #x1159 -| [#x115F-#x1161] -| #x1163 -| #x1165 -| #x1167 -| #x1169 -| [#x116D-#x116E] -| [#x1172-#x1173] -| #x1175 -| #x119E -| #x11A8 -| #x11AB -| [#x11AE-#x11AF] -| [#x11B7-#x11B8] -| #x11BA -| [#x11BC-#x11C2] -| #x11EB -| #x11F0 -| #x11F9 -| [#x1E00-#x1E9B] -| [#x1EA0-#x1EF9] -| [#x1F00-#x1F15] -| [#x1F18-#x1F1D] -| [#x1F20-#x1F45] -| [#x1F48-#x1F4D] -| [#x1F50-#x1F57] -| #x1F59 -| #x1F5B -| #x1F5D -| [#x1F5F-#x1F7D] -| [#x1F80-#x1FB4] -| [#x1FB6-#x1FBC] -| #x1FBE -| [#x1FC2-#x1FC4] -| [#x1FC6-#x1FCC] -| [#x1FD0-#x1FD3] -| [#x1FD6-#x1FDB] -| [#x1FE0-#x1FEC] -| [#x1FF2-#x1FF4] -| [#x1FF6-#x1FFC] -| #x2126 -| [#x212A-#x212B] -| #x212E -| [#x2180-#x2182] -| [#x3041-#x3094] -| [#x30A1-#x30FA] -| [#x3105-#x312C] -| [#xAC00-#xD7A3] -</rhs></prod> -<prod id="NT-Ideographic"><lhs>Ideographic</lhs> -<rhs>[#x4E00-#x9FA5] -| #x3007 -| [#x3021-#x3029] -</rhs></prod> -<prod id="NT-CombiningChar"><lhs>CombiningChar</lhs> -<rhs>[#x0300-#x0345] -| [#x0360-#x0361] -| [#x0483-#x0486] -| [#x0591-#x05A1] -| [#x05A3-#x05B9] -| [#x05BB-#x05BD] -| #x05BF -| [#x05C1-#x05C2] -| #x05C4 -| [#x064B-#x0652] -| #x0670 -| [#x06D6-#x06DC] -| [#x06DD-#x06DF] -| [#x06E0-#x06E4] -| [#x06E7-#x06E8] -| [#x06EA-#x06ED] -| [#x0901-#x0903] -| #x093C -| [#x093E-#x094C] -| #x094D -| [#x0951-#x0954] -| [#x0962-#x0963] -| [#x0981-#x0983] -| #x09BC -| #x09BE -| #x09BF -| [#x09C0-#x09C4] -| [#x09C7-#x09C8] -| [#x09CB-#x09CD] -| #x09D7 -| [#x09E2-#x09E3] -| #x0A02 -| #x0A3C -| #x0A3E -| #x0A3F -| [#x0A40-#x0A42] -| [#x0A47-#x0A48] -| [#x0A4B-#x0A4D] -| [#x0A70-#x0A71] -| [#x0A81-#x0A83] -| #x0ABC -| [#x0ABE-#x0AC5] -| [#x0AC7-#x0AC9] -| [#x0ACB-#x0ACD] -| [#x0B01-#x0B03] -| #x0B3C -| [#x0B3E-#x0B43] -| [#x0B47-#x0B48] -| [#x0B4B-#x0B4D] -| [#x0B56-#x0B57] -| [#x0B82-#x0B83] -| [#x0BBE-#x0BC2] -| [#x0BC6-#x0BC8] -| [#x0BCA-#x0BCD] -| #x0BD7 -| [#x0C01-#x0C03] -| [#x0C3E-#x0C44] -| [#x0C46-#x0C48] -| [#x0C4A-#x0C4D] -| [#x0C55-#x0C56] -| [#x0C82-#x0C83] -| [#x0CBE-#x0CC4] -| [#x0CC6-#x0CC8] -| [#x0CCA-#x0CCD] -| [#x0CD5-#x0CD6] -| [#x0D02-#x0D03] -| [#x0D3E-#x0D43] -| [#x0D46-#x0D48] -| [#x0D4A-#x0D4D] -| #x0D57 -| #x0E31 -| [#x0E34-#x0E3A] -| [#x0E47-#x0E4E] -| #x0EB1 -| [#x0EB4-#x0EB9] -| [#x0EBB-#x0EBC] -| [#x0EC8-#x0ECD] -| [#x0F18-#x0F19] -| #x0F35 -| #x0F37 -| #x0F39 -| #x0F3E -| #x0F3F -| [#x0F71-#x0F84] -| [#x0F86-#x0F8B] -| [#x0F90-#x0F95] -| #x0F97 -| [#x0F99-#x0FAD] -| [#x0FB1-#x0FB7] -| #x0FB9 -| [#x20D0-#x20DC] -| #x20E1 -| [#x302A-#x302F] -| #x3099 -| #x309A -</rhs></prod> -<prod id="NT-Digit"><lhs>Digit</lhs> -<rhs>[#x0030-#x0039] -| [#x0660-#x0669] -| [#x06F0-#x06F9] -| [#x0966-#x096F] -| [#x09E6-#x09EF] -| [#x0A66-#x0A6F] -| [#x0AE6-#x0AEF] -| [#x0B66-#x0B6F] -| [#x0BE7-#x0BEF] -| [#x0C66-#x0C6F] -| [#x0CE6-#x0CEF] -| [#x0D66-#x0D6F] -| [#x0E50-#x0E59] -| [#x0ED0-#x0ED9] -| [#x0F20-#x0F29] -</rhs></prod> -<prod id="NT-Extender"><lhs>Extender</lhs> -<rhs>#x00B7 -| #x02D0 -| #x02D1 -| #x0387 -| #x0640 -| #x0E46 -| #x0EC6 -| #x3005 -| [#x3031-#x3035] -| [#x309D-#x309E] -| [#x30FC-#x30FE] -</rhs></prod> - -</prodgroup> -</scrap> -</p> -<p>The character classes defined here can be derived from the -Unicode character database as follows: -<ulist> -<item> -<p>Name start characters must have one of the categories Ll, Lu, -Lo, Lt, Nl.</p> -</item> -<item> -<p>Name characters other than Name-start characters -must have one of the categories Mc, Me, Mn, Lm, or Nd.</p> -</item> -<item> -<p>Characters in the compatibility area (i.e. with character code -greater than #xF900 and less than #xFFFE) are not allowed in XML -names.</p> -</item> -<item> -<p>Characters which have a font or compatibility decomposition (i.e. those -with a "compatibility formatting tag" in field 5 of the database -- -marked by field 5 beginning with a "<") are not allowed.</p> -</item> -<item> -<p>The following characters are treated as name-start characters -rather than name characters, because the property file classifies -them as Alphabetic: [#x02BB-#x02C1], #x0559, #x06E5, #x06E6.</p> -</item> -<item> -<p>Characters #x20DD-#x20E0 are excluded (in accordance with -Unicode, section 5.14).</p> -</item> -<item> -<p>Character #x00B7 is classified as an extender, because the -property list so identifies it.</p> -</item> -<item> -<p>Character #x0387 is added as a name character, because #x00B7 -is its canonical equivalent.</p> -</item> -<item> -<p>Characters ':' and '_' are allowed as name-start characters.</p> -</item> -<item> -<p>Characters '-' and '.' are allowed as name characters.</p> -</item> -</ulist> -</p> -</div1> -<inform-div1 id="sec-xml-and-sgml"> -<head>XML and SGML</head> - -<p>XML is designed to be a subset of SGML, in that every -<termref def="dt-valid">valid</termref> XML document should also be a -conformant SGML document. -For a detailed comparison of the additional restrictions that XML places on -documents beyond those of SGML, see <bibref ref="Clark"/>. -</p> -</inform-div1> -<inform-div1 id="sec-entexpand"> -<head>Expansion of Entity and Character References</head> -<p>This appendix contains some examples illustrating the -sequence of entity- and character-reference recognition and -expansion, as specified in <specref ref="entproc"/>.</p> -<p> -If the DTD contains the declaration -<eg><![CDATA[<!ENTITY example "<p>An ampersand (&#38;) may be escaped -numerically (&#38;#38;) or with a general entity -(&amp;).</p>" > -]]></eg> -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>": -<eg><![CDATA[<p>An ampersand (&) may be escaped -numerically (&#38;) or with a general entity -(&amp;).</p> -]]></eg> -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): -<eg><![CDATA[An ampersand (&) may be escaped -numerically (&) or with a general entity -(&). -]]></eg> -</p> -<p>A more complex example will illustrate the rules and their -effects fully. In the following example, the line numbers are -solely for reference. -<eg><![CDATA[1 <?xml version='1.0'?> -2 <!DOCTYPE test [ -3 <!ELEMENT test (#PCDATA) > -4 <!ENTITY % xx '%zz;'> -5 <!ENTITY % zz '<!ENTITY tricky "error-prone" >' > -6 %xx; -7 ]> -8 <test>This sample shows a &tricky; method.</test> -]]></eg> -This produces the following: -<ulist spacing="compact"> -<item><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></item> -<item><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></item> -<item><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></item> -<item><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 -<emph>This sample shows a error-prone method.</emph> -</p></item> -</ulist> -</p> -</inform-div1> -<inform-div1 id="determinism"> -<head>Deterministic Content Models</head> -<p><termref def="dt-compat">For compatibility</termref>, it is -required -that content models in element type declarations be deterministic. -</p> -<!-- FINAL EDIT: WebSGML allows ambiguity? --> -<p>SGML -requires deterministic content models (it calls them -"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 parser -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 parser 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 <bibref ref="Aho"/>. -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 <bibref ref="ABK"/>.</p> -</inform-div1> -<inform-div1 id="sec-guessing"> -<head>Autodetection of Character Encodings</head> -<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> -<p> -Because each XML entity not in UTF-8 or UTF-16 format <emph>must</emph> -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>".</p> -<p> -<ulist> -<item> -<p><code>00 00 00 3C</code>: UCS-4, big-endian machine (1234 order)</p> -</item> -<item> -<p><code>3C 00 00 00</code>: UCS-4, little-endian machine (4321 order)</p> -</item> -<item> -<p><code>00 00 3C 00</code>: UCS-4, unusual octet order (2143)</p> -</item> -<item> -<p><code>00 3C 00 00</code>: UCS-4, unusual octet order (3412)</p> -</item> -<item> -<p><code>FE FF</code>: UTF-16, big-endian</p> -</item> -<item> -<p><code>FF FE</code>: UTF-16, little-endian</p> -</item> -<item> -<p><code>00 3C 00 3F</code>: UTF-16, big-endian, no Byte Order Mark -(and thus, strictly speaking, in error)</p> -</item> -<item> -<p><code>3C 00 3F 00</code>: UTF-16, little-endian, no Byte Order Mark -(and thus, strictly speaking, in error)</p> -</item> -<item> -<p><code>3C 3F 78 6D</code>: 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 ASCII characters, the encoding -declaration itself may be read reliably -</p> -</item> -<item> -<p><code>4C 6F A7 94</code>: EBCDIC (in some flavor; the full -encoding declaration must be read to tell which code page is in -use)</p> -</item> -<item> -<p>other: UTF-8 without an encoding declaration, or else -the data stream is corrupt, fragmentary, or enclosed in -a wrapper of some kind</p> -</item> -</ulist> -</p> -<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 -ASCII characters, 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. -</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> -<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. -Rules for the relative priority of the internal label and the -MIME-type label in an external header, for example, should be part of the -RFC document defining the text/xml and application/xml MIME types. In -the interests of interoperability, however, the following rules -are recommended. -<ulist> -<item><p>If an XML entity is in a file, the Byte-Order Mark -and encoding-declaration PI are used (if present) to determine the -character encoding. All other heuristics and sources of information -are solely for error recovery. -</p></item> -<item><p>If an XML entity is delivered with a -MIME type of text/xml, then the <code>charset</code> parameter -on the MIME type determines the -character encoding method; all other heuristics and sources of -information are solely for error recovery. -</p></item> -<item><p>If an XML entity is delivered -with a -MIME type of application/xml, then the Byte-Order Mark and -encoding-declaration PI are used (if present) to determine the -character encoding. All other heuristics and sources of -information are solely for error recovery. -</p></item> -</ulist> -These rules apply only in the absence of protocol-level documentation; -in particular, when the MIME types text/xml and application/xml are -defined, the recommendations of the relevant RFC will supersede -these rules. -</p> - -</inform-div1> - -<inform-div1 id="sec-xml-wg"> -<head>W3C XML Working Group</head> - -<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 members voted for its approval. -The current and former members of the XML WG are:</p> - -<orglist> -<member><name>Jon Bosak, Sun</name><role>Chair</role></member> -<member><name>James Clark</name><role>Technical Lead</role></member> -<member><name>Tim Bray, Textuality and Netscape</name><role>XML Co-editor</role></member> -<member><name>Jean Paoli, Microsoft</name><role>XML Co-editor</role></member> -<member><name>C. M. Sperberg-McQueen, U. of Ill.</name><role>XML -Co-editor</role></member> -<member><name>Dan Connolly, W3C</name><role>W3C Liaison</role></member> -<member><name>Paula Angerstein, Texcel</name></member> -<member><name>Steve DeRose, INSO</name></member> -<member><name>Dave Hollander, HP</name></member> -<member><name>Eliot Kimber, ISOGEN</name></member> -<member><name>Eve Maler, ArborText</name></member> -<member><name>Tom Magliery, NCSA</name></member> -<member><name>Murray Maloney, Muzmo and Grif</name></member> -<member><name>Makoto Murata, Fuji Xerox Information Systems</name></member> -<member><name>Joel Nava, Adobe</name></member> -<member><name>Conleth O'Connell, Vignette</name></member> -<member><name>Peter Sharpe, SoftQuad</name></member> -<member><name>John Tigue, DataChannel</name></member> -</orglist> - -</inform-div1> -</back> -</spec> -<!-- Keep this comment at the end of the file -Local variables: -mode: sgml -sgml-default-dtd-file:"~/sgml/spec.ced" -sgml-omittag:t -sgml-shorttag:t -End: ---> |