9/13/2016
`
`Extensible Markup Language (XML) 1.0
`
`http://www12.w3.org/TR/1998/REC­xml­19980210
`
`Go
`
`775 captures
`13 Feb 98 ­ 26 Aug 16
`
`FEB JUL APR3
`
`1997 1998 1999
`
`REC­xml­19980210
`
`Extensible Markup Language (XML) 1.0
`
`W3C Recommendation 10­February­1998
`
`This version:
`http://www.w3.org/TR/1998/REC­xml­19980210
`http://www.w3.org/TR/1998/REC­xml­19980210.xml
`http://www.w3.org/TR/1998/REC­xml­19980210.html
`http://www.w3.org/TR/1998/REC­xml­19980210.pdf
`http://www.w3.org/TR/1998/REC­xml­19980210.ps
`Latest version:
`http://www.w3.org/TR/REC­xml
`Previous version:
`http://www.w3.org/TR/PR­xml­971208
`Editors:
`Tim Bray (Textuality and Netscape) <tbray@textuality.com>
`Jean Paoli (Microsoft) <jeanpa@microsoft.com>
`C. M. Sperberg­McQueen (University of Illinois at Chicago) <cmsmcq@uic.edu>
`Abstract
`
`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.
`Status of this document
`
`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.
`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 http://www.w3.org/XML. A list of current W3C
`Recommendations and other technical documents can be found at http://www.w3.org/TR.
`This specification uses the term URI, which is defined by [Berners­Lee et al.], a work in progress expected to update
`[IETF RFC1738] and [IETF RFC1808].
`The list of known errors in this specification is available at http://www.w3.org/XML/xml­19980210­errata.
`Please report errors in this document to xml­editor@w3.org.
`
`Extensible Markup Language (XML) 1.0
`Table of Contents
`
`1. Introduction
`    1.1 Origin and Goals
`    1.2 Terminology
`2. Documents
`    2.1 Well­Formed XML Documents
`
`https://web.archive.org/web/19980703174959/http://www12.w3.org/TR/1998/REC­xml­19980210
`
`1/27
`
`Netflix 1038 - Page 1
`
`

`
`Go
`
`FEB JUL APR3
`
`1997 1998 1999
`
`9/13/2016
`
`Extensible Markup Language (XML) 1.0
`
`    2.2 Characters
`http://www12.w3.org/TR/1998/REC­xml­19980210
`    2.3 Common Syntactic Constructs
`775 captures
`    2.4 Character Data and Markup
`13 Feb 98 ­ 26 Aug 16
`    2.5 Comments
`    2.6 Processing Instructions
`    2.7 CDATA Sections
`    2.8 Prolog and Document Type Declaration
`    2.9 Standalone Document Declaration
`    2.10 White Space Handling
`    2.11 End­of­Line Handling
`    2.12 Language Identification
`3. Logical Structures
`3.1 Start­Tags, End­Tags, and Empty­Element Tags
`3.2 Element Type Declarations
`        3.2.1 Element Content
`        3.2.2 Mixed Content
`    3.3 Attribute­List Declarations
`        3.3.1 Attribute Types
`        3.3.2 Attribute Defaults
`        3.3.3 Attribute­Value Normalization
`    3.4 Conditional Sections
`4. Physical Structures
`4.1 Character and Entity References
`4.2 Entity Declarations
`        4.2.1 Internal Entities
`        4.2.2 External Entities
`    4.3 Parsed Entities
`        4.3.1 The Text Declaration
`        4.3.2 Well­Formed Parsed Entities
`        4.3.3 Character Encoding in Entities
`    4.4 XML Processor Treatment of Entities and References
`        4.4.1 Not Recognized
`        4.4.2 Included
`        4.4.3 Included If Validating
`        4.4.4 Forbidden
`        4.4.5 Included in Literal
`        4.4.6 Notify
`        4.4.7 Bypassed
`        4.4.8 Included as PE
`    4.5 Construction of Internal Entity Replacement Text
`    4.6 Predefined Entities
`    4.7 Notation Declarations
`    4.8 Document Entity
`5. Conformance
`5.1 Validating and Non­Validating Processors
`5.2 Using XML Processors
`6. Notation
`
`Appendices
`
`A. References
`A.1 Normative References
`A.2 Other References
`B. Character Classes
`C. XML and SGML (Non­Normative)
`D. Expansion of Entity and Character References (Non­Normative)
`E. Deterministic Content Models (Non­Normative)
`F. Autodetection of Character Encodings (Non­Normative)
`G. W3C XML Working Group (Non­Normative)
`
`1. Introduction
`
`https://web.archive.org/web/19980703174959/http://www12.w3.org/TR/1998/REC­xml­19980210
`
`2/27
`
`Netflix 1038 - Page 2
`
`

`
`9/13/2016
`
`Extensible Markup Language (XML) 1.0
`Extensible Markup Language, abbreviated XML, describes a class of data objects called XML documents and partially
`FEB JUL APR3
`http://www12.w3.org/TR/1998/REC­xml­19980210
`Go
`describes  the  behavior  of  computer  programs  which  process  them.  XML  is  an  application  profile  or  restricted  form  of
`775 captures
`SGML, the Standard Generalized Markup Language [ISO 8879]. By construction, XML documents are conforming SGML
`1997 1998 1999
`13 Feb 98 ­ 26 Aug 16
`documents.
`XML documents are made up of storage units called entities, which contain either parsed or unparsed data. Parsed data is
`made up of characters, some of which form character data, and some of which form markup. 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.
`A software module called an XML processor is used to read XML documents and provide access to their content and
`structure. It is assumed that an XML processor is doing its work on behalf of another module, called the application. 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.
`
`1.1 Origin and Goals
`
`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.
`The design goals for XML are:
`
`1. XML shall be straightforwardly usable over the Internet.
`2. XML shall support a wide variety of applications.
`3. XML shall be compatible with SGML.
`4. It shall be easy to write programs which process XML documents.
`5. The number of optional features in XML is to be kept to the absolute minimum, ideally zero.
`6. XML documents should be human­legible and reasonably clear.
`7. The XML design should be prepared quickly.
`8. The design of XML shall be formal and concise.
`9. XML documents shall be easy to create.
`10. Terseness in XML markup is of minimal importance.
`
`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 1.0 and construct computer programs to process it.
`This version of the XML specification may be distributed freely, as long as all text and legal notices remain intact.
`
`1.2 Terminology
`
`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:
`may
`
`Conforming documents and XML processors are permitted to but need not behave as described.
`
`Conforming documents and XML processors are required to behave as described; otherwise they are in error.
`
`must
`
`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.
`fatal error
`An error which a conforming XML processor 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).
`at user option
`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.
`validity constraint
`A rule which applies to all valid  XML  documents. Violations  of  validity  constraints  are  errors;  they  must,  at  user
`option, be reported by validating XML processors.
`
`https://web.archive.org/web/19980703174959/http://www12.w3.org/TR/1998/REC­xml­19980210
`
`3/27
`
`Netflix 1038 - Page 3
`
`

`
`9/13/2016
`
`Extensible Markup Language (XML) 1.0
`
`well­formedness constraint
`FEB JUL APR3
`http://www12.w3.org/TR/1998/REC­xml­19980210
`Go
`A rule which applies to all well­formed XML documents. Violations of well­formedness constraints are fatal errors.
`775 captures
`match
`1997 1998 1999
`13 Feb 98 ­ 26 Aug 16
`(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 "Element Valid".
`for compatibility
`A feature of XML included solely to ensure that XML remains compatible with SGML.
`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 Adaptations Annex to ISO 8879.
`2. Documents
`
`A data object is an XML document if it is well­formed, as defined in this specification. A well­formed XML document
`may in addition be valid if it meets certain further constraints.
`Each XML document has both a logical and a physical structure. Physically, the document is composed of units called
`entities. An entity may refer to other entities to cause their inclusion in the document. A document begins in a "root" or
`document  entity.  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 "4.3.2 Well­Formed Parsed Entities".
`
`2.1 Well­Formed XML Documents
`
`A textual object is a well­formed XML document if:
`
`1. Taken as a whole, it matches the production labeled document.
`2. It meets all the well­formedness constraints given in this specification.
`3. Each of the parsed entities which is referenced directly or indirectly within the document is well­formed.
`
`Document
`
`[1]  document ::= prolog element Misc*
`Matching the document production implies that:
`
`1. It contains one or more elements.
`2. There is exactly one element, called the root, or document element, no part of which appears in the content of any
`other element. 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.
`
`As a consequence of this, for each non­root element C in the document, there is one other element P in the document such
`that C is in the content of P, but is not in the content of any other element that is in the content of P. P is referred to as the
`parent of C, and C as a child of P.
`
`2.2 Characters
`
`A parsed entity contains text, a sequence of characters, which may represent markup or character data. A character is an
`atomic unit of text as specified by ISO/IEC 10646 [ISO/IEC 10646]. 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 [Unicode], is discouraged.
`Character Range
`
`[2]  Char ::= #x9 | #xA | #xD | [#x20‐#xD7FF] | [#xE000‐
`/* any Unicode character, excluding the surrogate
`blocks, FFFE, and FFFF. */
`#xFFFD] | [#x10000‐#x10FFFF]
`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
`
`https://web.archive.org/web/19980703174959/http://www12.w3.org/TR/1998/REC­xml­19980210
`
`4/27
`
`Netflix 1038 - Page 4
`
`

`
`9/13/2016
`
`Extensible Markup Language (XML) 1.0
`bringing other encodings into play, are discussed later, in "4.3.3 Character Encoding in Entities".
`http://www12.w3.org/TR/1998/REC­xml­19980210
`Go
`775 captures
`2.3 Common Syntactic Constructs
`13 Feb 98 ­ 26 Aug 16
`
`FEB JUL APR3
`
`1997 1998 1999
`
`This section defines some symbols used widely in the grammar.
`S (white space) consists of one or more space (#x20) characters, carriage returns, line feeds, or tabs.
`White Space
`
`[3]  S ::= (#x20 | #x9 | #xD | #xA)+
`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 "B. Character Classes".
`A Name is a token beginning with a letter or one of a few punctuation characters, and continuing with letters, digits,
`hyphens, underscores, colons, or full stops, together known as name characters. Names beginning with the string "xml", or
`any string which would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for standardization in this or future versions
`of this specification.
`Note: 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.
`An Nmtoken (name token) is any mixture of name characters.
`Names and Tokens
`
`[4]  NameChar ::= Letter | Digit | '.' | '‐' | '_' | ':' | CombiningChar | Extender
`[5] 
`Name ::= (Letter | '_' | ':') (NameChar)*
`[6] 
`Names ::= Name (S Name)*
`[7]  Nmtoken ::= (NameChar)+
`[8]  Nmtokens ::= Nmtoken (S Nmtoken)*
`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  (EntityValue),  the  values  of  attributes  (AttValue),  and  external  identifiers
`(SystemLiteral). Note that a SystemLiteral can be parsed without scanning for markup.
`Literals
`
`[9] 
`
`[10] 
`
`EntityValue ::= '"' ([^%&"] | PEReference | Reference)* '"'
`|  "'" ([^%&'] | PEReference | Reference)* "'"
`AttValue ::= '"' ([^<&"] | Reference)* '"'
`|  "'" ([^<&'] | Reference)* "'"
`[11]  SystemLiteral ::= ('"' [^"]* '"') | ("'" [^']* "'")
`[12]  PubidLiteral ::= '"' PubidChar* '"' | "'" (PubidChar ‐ "'")* "'"
`[13] 
`PubidChar ::= #x20 | #xD | #xA | [a‐zA‐Z0‐9] | [‐'()+,./:=?;!*#@$_%]
`
`2.4 Character Data and Markup
`
`Text consists of intermingled character data and markup. Markup takes the form of start­tags, end­tags, empty­element
`tags,  entity  references,  character  references,  comments,  CDATA  section  delimiters,  document  type  declarations,  and
`processing instructions.
`All text that is not markup constitutes the character data of the document.
`The ampersand character (&) and the left angle bracket (<) may appear in their literal form only when used as markup
`delimiters, or within a comment, a processing instruction, or a CDATA section. They are also legal within the literal entity
`value of an internal entity declaration; see "4.3.2 Well­Formed Parsed Entities". If they are needed elsewhere, they must be
`escaped using either numeric character references or the strings "&amp;" and "&lt;" respectively. The right angle bracket (>)
`may be represented using the string "&gt;", and must, for compatibility, be escaped using "&gt;" or a character reference
`when it appears in the string "]]>" in content, when that string is not marking the end of a CDATA section.
`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,
`"]]>".
`
`https://web.archive.org/web/19980703174959/http://www12.w3.org/TR/1998/REC­xml­19980210
`
`5/27
`
`Netflix 1038 - Page 5
`
`

`
`9/13/2016
`
`Extensible Markup Language (XML) 1.0
`To allow attribute values to contain both single and double quotes, the apostrophe or single­quote character (') may be
`FEB JUL APR3
`http://www12.w3.org/TR/1998/REC­xml­19980210
`Go
`represented as "&apos;", and the double­quote character (") as "&quot;".
`775 captures
`Character Data
`13 Feb 98 ­ 26 Aug 16
`
`1997 1998 1999
`
`[14]  CharData ::= [^<&]* ‐ ([^<&]* ']]>' [^<&]*)
`
`2.5 Comments
`
`Comments may appear anywhere in a document outside other markup; in addition, they may appear within the document
`type declaration at places allowed by the grammar. They are not part of the document's character data; an XML processor
`may, but need not, make it possible for an application to retrieve the text of comments. For compatibility, the string "‐‐"
`(double­hyphen) must not occur within comments.
`Comments
`
`[15]  Comment ::= '<!‐‐' ((Char ‐ '‐') | ('‐' (Char ‐ '‐')))* '‐‐>'
`An example of a comment:
`<!‐‐ declarations for <head> & <body> ‐‐>
`
`2.6 Processing Instructions
`
`Processing instructions (PIs) allow documents to contain instructions for applications.
`Processing Instructions
`
`[16] 
`PI ::= '<?' PITarget (S (Char* ‐ (Char* '?>' Char*)))? '?>'
`[17]  PITarget ::= Name ‐ (('X' | 'x') ('M' | 'm') ('L' | 'l'))
`PIs are not part of the document's character data, but must be passed through to the application. The PI begins with a
`target (PITarget) used to identify the application to which the instruction is directed. The target names "XML", "xml", and so
`on are reserved for standardization in this or future versions of this specification. The XML Notation mechanism may be
`used for formal declaration of PI targets.
`
`2.7 CDATA Sections
`
`CDATA  sections  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 "<![CDATA[" and end
`with the string "]]>":
`CDATA Sections
`
`[18]  CDSect ::= CDStart CData CDEnd
`[19]  CDStart ::= '<![CDATA['
`[20] 
`CData ::= (Char* ‐ (Char* ']]>' Char*))
`[21] 
`CDEnd ::= ']]>'
`Within a CDATA section, only the CDEnd 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 "&lt;" and "&amp;". CDATA sections cannot nest.
`An example of a CDATA section, in which "<greeting>" and "</greeting>" are recognized as character data, not markup:
`<![CDATA[<greeting>Hello, world!</greeting>]]>
`
`2.8 Prolog and Document Type Declaration
`
`XML documents may, and should, begin with an XML declaration which specifies the version of XML being used. For
`example, the following is a complete XML document, well­formed but not valid:
`<?xml version="1.0"?>
`<greeting>Hello, world!</greeting>
`and so is this:
`<greeting>Hello, world!</greeting>
`
`https://web.archive.org/web/19980703174959/http://www12.w3.org/TR/1998/REC­xml­19980210
`
`6/27
`
`Netflix 1038 - Page 6
`
`

`
`9/13/2016
`
`Extensible Markup Language (XML) 1.0
`The version number "1.0" should be used to indicate conformance to this version of this specification; it is an error for a
`FEB JUL APR3
`http://www12.w3.org/TR/1998/REC­xml­19980210
`Go
`document to use the value "1.0" if  it  does  not  conform  to  this  version  of  this  specification.  It  is  the  intent  of  the  XML
`775 captures
`working  group  to  give  later  versions  of  this  specification  numbers  other  than  "1.0",  but  this  intent  does  not  indicate  a
`1997 1998 1999
`13 Feb 98 ­ 26 Aug 16
`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.
`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 document type declaration, to define constraints on
`the logical structure and to support the use of predefined storage units. An XML document is valid if it has an associated
`document type declaration and if the document complies with the constraints expressed in it.
`The document type declaration must appear before the first element in the document.
`Prolog
`
`[22] 
`prolog ::= XMLDecl? Misc* (doctypedecl Misc*)?
`[23] 
`XMLDecl ::= '<?xml' VersionInfo EncodingDecl? SDDecl? S? '?>'
`[24]  VersionInfo ::= S 'version' Eq (' VersionNum ' | " VersionNum ")
`[25] 
`Eq ::= S? '=' S?
`[26]  VersionNum ::= ([a‐zA‐Z0‐9_.:] | '‐')+
`[27] 
`Misc ::= Comment | PI |  S
`The XML document type declaration contains or points to markup declarations that provide a grammar for a class of
`documents. This grammar is known as a document type definition, or DTD. The document type declaration can point to an
`external subset (a special kind of external entity) 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.
`A markup declaration is an element type declaration, an attribute­list declaration, an entity declaration, or a notation
`declaration. These declarations may be contained in whole or in part within parameter entities, as described in the well­
`formedness and validity constraints below. For fuller information, see "4. Physical Structures".
`Document Type Definition
`
`[ VC: Root Element Type ]
`
`[28]  doctypedecl ::= '<!DOCTYPE' S Name (S ExternalID)? S? ('[' (markupdecl
`| PEReference | S)* ']' S?)? '>'
`[29]  markupdecl ::= elementdecl | AttlistDecl | EntityDecl | NotationDecl | PI
`| Comment
`
`[ VC: Proper
`Declaration/PE Nesting ]
`[ WFC: PEs in Internal
`Subset ]
`The  markup  declarations  may  be  made  up  in  whole  or  in  part  of  the  replacement  text  of  parameter  entities.  The
`productions  later  in  this  specification  for  individual  nonterminals  (elementdecl,  AttlistDecl,  and  so  on)  describe  the
`declarations after all the parameter entities have been included.
`Validity Constraint: Root Element Type
`The Name in the document type declaration must match the element type of the root element.
`Validity Constraint: Proper Declaration/PE Nesting
`Parameter­entity  replacement  text  must  be  properly  nested  with  markup  declarations.  That  is  to  say,  if  either  the  first
`character  or  the  last  character  of  a  markup  declaration  (markupdecl  above)  is  contained  in  the  replacement  text  for  a
`parameter­entity reference, both must be contained in the same replacement text.
`Well­Formedness Constraint: PEs in Internal Subset
`In the internal DTD subset, parameter­entity references 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.)
`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 markupdecl, interspersed with white
`space  or  parameter­entity references.  However,  portions  of  the  contents  of  the  external  subset  or  of  external  parameter
`entities may conditionally be ignored by using the conditional section construct; this is not allowed in the internal subset.
`External Subset
`
`[30] 
`extSubset ::= TextDecl? extSubsetDecl
`[31]  extSubsetDecl ::= ( markupdecl | conditionalSect | PEReference | S )*
`The external subset and external parameter entities also differ from the internal subset in that in them, parameter­entity
`references are permitted within markup declarations, not only between markup declarations.
`An example of an XML document with a document type declaration:
`
`https://web.archive.org/web/19980703174959/http://www12.w3.org/TR/1998/REC­xml­19980210
`
`7/27
`
`Netflix 1038 - Page 7
`
`

`
`9/13/2016
`
`Extensible Markup Language (XML) 1.0
`
`Go
`
`<?xml version="1.0"?>
`http://www12.w3.org/TR/1998/REC­xml­19980210
`<!DOCTYPE greeting SYSTEM "hello.dtd">
`<greeting>Hello, world!</greeting>
`775 captures
`13 Feb 98 ­ 26 Aug 16
`The system identifier "hello.dtd" gives the URI of a DTD for the document.
`The declarations can also be given locally, as in this example:
`<?xml version="1.0" encoding="UTF‐8" ?>
`<!DOCTYPE greeting [
`  <!ELEMENT greeting (#PCDATA)>
`]>
`<greeting>Hello, world!</greeting>
`If both the external and internal subsets are used, the internal subset is considered to occur before the external subset. This
`has  the  effect  that  entity  and  attribute­list  declarations  in  the  internal  subset  take  precedence  over  those  in  the  external
`subset.
`2.9 Standalone Document Declaration
`
`FEB JUL APR3
`
`1997 1998 1999
`
`Markup  declarations  can  affect  the  content  of  the  document,  as  passed  from  an  XML  processor  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
`document entity.
`Standalone Document Declaration
`
`[32]  SDDecl ::= S 'standalone' Eq (("'" ('yes' | 'no') "'") | ('"' ('yes'
`[ VC: Standalone Document
`Declaration ]
`| 'no') '"'))
`In  a  standalone  document  declaration,  the  value  "yes"  indicates  that  there  are  no  markup  declarations  external  to  the
`document entity (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 "no" indicates that there are or
`may  be  such  external  markup  declarations.  Note  that  the  standalone  document  declaration  only  denotes  the  presence  of
`external declarations;  the  presence,  in  a  document,  of  references  to  external  entities,  when  those  entities  are  internally
`declared, does not change its standalone status.
`If there are no external markup declarations, the standalone document declaration has no meaning. If there are external
`markup declarations but there is no standalone document declaration, the value "no" is assumed.
`Any XML document for which standalone="no" holds can be converted algorithmically to a standalone document, which
`may be desirable for some network delivery applications.
`Validity Constraint: Standalone Document Declaration
`The standalone document declaration must have the value "no" if any external markup declarations contain declarations of:
`
`attributes  with  default  values,  if  elements  to  which  these  attributes  apply  appear  in  the  document  without
`specifications of values for these attributes, or
`entities (other than amp, lt, gt, apos, quot), if references to those entities appear in the document, or
`attributes with values subject to normalization, where the attribute appears in the document with a value which will
`change as a result of normalization, or
`element types with element content, if white space occurs directly within any instance of those types.
`
`An example XML declaration with a standalone document declaration:
`<?xml version="1.0" standalone='yes'?>
`
`2.10 White Space Handling
`
`In editing XML documents, it is often convenient to use "white space" (spaces, tabs, and blank lines, denoted by the
`nonterminal S 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.
`An XML processor must  always  pass  all  characters  in  a  document  that  are  not  markup  through  to  the  application.  A
`validating XML processor must also inform the application which of these characters constitute white space appearing in
`element content.
`A special attribute named xml:space 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 declared if it is used. When
`declared, it must be given as an enumerated type whose only possible values are "default" and "preserve". For example:
`    <!ATTLIST poem   xml:space (default|preserve) 'preserve'>
`
`https://web.archive.org/web/19980703174959/http://www12.w3.org/TR/1998/REC­xml­19980210
`
`8/27
`
`Netflix 1038 - Page 8
`
`

`
`9/13/2016
`
`Extensible Markup Language (XML) 1.0
`The value "default" signals that applications' default white­space processing modes are acceptable for this element; the
`FEB JUL APR3
`http://www12.w3.org/TR/1998/REC­xml­19980210
`Go
`value "preserve" indicates the intent that applications preserve all the white space. This declared intent is considered to
`775 captures
`apply to all elements within the content of the element where it is specified, unless overriden with another instance of the
`1997 1998 1999
`13 Feb 98 ­ 26 Aug 16
`xml:space attribute.
`The root element 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.
`
`2.11 End­of­Line Handling
`
`XML parsed entities 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).
`To simplify the tasks of applications, 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 XML processor 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.)
`
`2.12 Language Identification
`
`In document processing, it is often useful to identify the natural or formal language in which the content is written. A
`special attribute named xml:lang 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 declared if it is used.
`The  values  of  the  attribute  are  language  identifiers  as  defined  by  [IETF  RFC  1766],  "Tags  for  the  Identification  of
`Languages":
`Language Identification
`
`[33]  LanguageID ::= Langcode ('‐' Subcode)*
`[34] 
`Langcode ::= ISO639Code |  IanaCode |  UserCode
`[35]  ISO639Code ::= ([a‐z] | [A‐Z]) ([a‐z] |