| <?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></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=" |