www.archive.org
`
`415.561.6767
`
`415.840-0391 e-fax
`
`Internet Archive
`
`300 Funston Avenue
`
`San Francisco. CA 94118
`
`AFFIDAVIT OF CHRISTOPHER BUTLER
`
`1.1 am the Office Manager at the Internet Archive, located in San Francisco,
`California. I make this declaration of my own personal knowledge.
`2. The Internet Archive is a website that provides access to a digital library of
`Internet sites and other cultural artifacts in digital form. Like a paper library, we provide
`free access to researchers, historians, scholars, and the general public. The Internet
`Archive has partnered with and receives support from various institutions, including the
`Library of Congress.
`3. The Internet Archive has created a service known as the Wayback Machine. The
`Wayback Machine makes it possible to surf more than 400 billion pages stored in the
`Internet Archive's web archive. Visitors to the Wayback Machine can search archives
`by URL (i.e., a website address). If archived records for a URL are available, the visitor
`will be presented with a list of available dates. The visitor may select one of those
`dates, and then begin surfing on an archived version of the Web. The links on the
`archived files, when served by the Wayback Machine, point to other archived files
`(whether HTML pages or images). If a visitor clicks on a link on an archived page, the
`Wayback Machine will serve the archived file with the closest available date to the page
`upon which the link appeared and was clicked.
`4. The archived data made viewable and browseable by the Wayback Machine is
`compiled using software programs known as crawlers, which surf the Web and
`automatically store copies of web files, preserving these files as they exist at the point of
`time of capture.
`5. The Internet Archive assigns a URL on its site to the archived files in the format
`http://web.archive.org/web/fYear in yyyy][Month in mm][Day in dd][Time code in
`hh:mm:ss]/[Archived URL], Thus, the Internet Archive URL
`http://web.archive.Org/web/19970126045828/http://www.archive.org/ would be the
`URL for the record of the Internet Archive home page HTML file
`(http://www.archive.org/) archived on January 26, 1997 at 4:58 a.m. and 28 seconds
`(1997/01/26 at 04:58:28). A web browser may be set such that a printout from it will
`display the URL of a web page in the printout's footer. The date assigned by the Internet
`Archive applies to the HTML file but not to image files linked therein. Thus images that
`appear on a page may not have been archived on the same date as the HTML file.
`Likewise, if a website is designed with "frames," the date assigned by the Internet
`Archive applies to the frameset as a whole, and not the individual pages within each
`frame.
`6. Attached hereto as Exhibit A are true and accurate copies of printouts of the
`Internet Archive's records of the HTML files for the URLs and the dates specified in the
`footer of the printout.
`7 . 1 d e c l a r e u n d e r p e n a l t y o f p e r j u r y t h a t t h e f o r e g o i n g i s t r u e a n d c o r r e c t .
`
`DATE:_ 5 (t*< j t 3
`
`_
`
`Christopher Butler
`
`IBM-1010
`Page 1 of 31
`
`

`

`CALIFORNIA JURAT
`
`See Attached Document.
`
`State of California
`County of San Francisco
`
`A notary public or other officer completing this
`certificate verifies only the identity of the
`individual who signed the document to which this
`certificate is atached, and not the truthfulness,
`accuracy, or validity of that document.
`
`Subscribed and sworn to (or affirmed) before me on
`this
`
`Christopher Butler,
`
`proved to me on the basis of satisfactory evidence to be
`the person who appeared before me.
`
`Signature:,^
`
`IBM-1010
`Page 2 of 31
`
`

`

`Exhibit A
`Exhibit A
`
`IBM-1010
`
`Page 3 of 31
`
`IBM-1010
`Page 3 of 31
`
`

`

`Extensible Markup Language (XML) 1.0
`
`1 of 28
`
`m
`
`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/RF.C-xml-l 9980210.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) <tbrav@textualitv.com>
`Jean Paoli (Microsoft) <ieanpa@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 IBerners-I.ee et al.1. a work in progress expected to update
`IIETF RFC17381 and 1IETF RFC 18081.
`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
`2.2 Characters
`
`https://web .archive.org/web/19980213212127/http:/www 13 .w3 .org/TR/REC-xml
`
`IBM-1010
`Page 4 of 31
`
`

`

`Extensible Markup Language (XML) 1.0
`
`2 of 28
`
`2.3 Common Syntactic Constructs
`2.4 Character Data and Markup
`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.l Normative References
`A.2 Other References
`B. Character Classes
`C. XML and SGML. INon-Normativel
`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)
`
`https://web .archive .org/web/19980213212127/http:/www 13 .w3 .org/TR/REC-xml
`
`IBM-1010
`Page 5 of 31
`
`

`

`Extensible Markup Language (XML) 1.0
`
`3 of 28
`
`1. Introduction
`
`Extensible Markup Language, abbreviated XML, describes a class of data objects called XML documents 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 IISO 88791. By construction, XML documents are conforming SGML
`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
`
`must
`
`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.
`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).
`
`https://web.archive.org/vveb/19980213212127/http:/www 13 ,w3 .org/TR/REC-xml
`
`IBM-1010
`Page 6 of 31
`
`

`

`Extensible Markup Language (XML) 1.0
`
`4 of 28
`
`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,
`well-formedness constraint
`A rule which applies to all well-formed XML documents. Violations of well-formedness constraints are fatal errors,
`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 "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
`
`HI document :: = prolog element Mise*
`
`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 USQ/IEC 106461. Legal characters are tab, carriage return, line feed, and
`
`https://vveb.archive.Org/vveb/19980213212127/http:/vvwvvl3.w3.org/TR/REC-xml
`
`IBM-1010
`Page 7 of 31
`
`

`

`Extensible Markup Language (XML) 1.0
`
`5 of 28
`
`the legal graphic characters of Unicode and ISO/IEC 10646. The use of "compatibility characters", as defined in section 6.8
`of rUnicodel, is discouraged.
`
`Character Range
`
`[2] Char ::=#x9 | #xA | #xD j [#x20-#xD7FF]
`1 [#xE000-#xFFFD] j [#xl0000-#xl0FFFF]
`
`/* any Unicode character, excluding the
`surrogate blocks, FFFE, and FFFF. */
`
`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 "4.3.3 Character Encoding in Entities".
`
`2.3 Common Syntactic Constructs
`
`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 "xmi", or
`any string which would match (( • x' | 'x') ( 'm' | • m1) ('L | ' 1')), 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 | Diqit | | | 1 ' | ' ' | CombininqChar | Extender
`
`[5]
`
`[5]
`
`Name : := (Letter | 11 |
`
`(NameChar)*
`
`Names : : = Name (S Name)*
`
`[7] Nmtoken : := (NameChar)+
`
`fg] 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
`
`PEReference | Reference)*
`
`C«
`
`<
`
`EntityValue :
`
`II
`
`[9]
`
`( r % & ] | PEReference | Reference)*
`Reference)*
`
`u3
`V
`<
`
`1
`
`AttValue :
`
`II
`
`[10|
`
`< r < & ] | Reference)*
`I
`[11] SystemLiteral : : = ( " " [ A " l * ' " ) 1
`I a , I *
`(
`
`)
`
`[12] PubidLiteral : ,i,i pubidchar* | (PubidChar - "1 " )*
`
`[13J
`
`PubidChar : :=#x20 ] #xO | #xA | [a-zA-ZO-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
`
`https://vveb.archive.Org/web/19980213212127/http:/wvvvvl3.vv3.org/TR/REC-xml
`
`IBM-1010
`Page 8 of 31
`
`

`

`Extensible Markup Language (XML) 1.0
`
`6 of 28
`
`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 fonn 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 "sgt;" 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,
`
`To allow attribute values to contain both single and double quotes, the apostrophe or single-quote character (') may be
`represented as "sapos;and the double-quote character (") as "squot;".
`
`Character Data
`
`[14] CharData ::= [A<&]* - ( [ * < & ] *
`
`' ] ] > ' [ ' < & ] * )
`
`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 ::= '<?' PITarqet (S (Char* - (Char* '?>' Char*)))? ' ?>'
`
`[17] PITarget : : = Name - (('X' | ' x' ) ('M' | 'm') ('L' | '1'))
`
`Pis are not part of the document's character data, but must be passed through to the application. The PI begins with a
`target (piTarqet) used to identify the application to which the instruction is directed. The target names "XML", "xmi", 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
`
`https://vveb .archi ve.org/web/19980213212127/http;/w ww 13 .vv3 .org/TR/REC-xml
`
`IBM-1010
`Page 9 of 31
`
`

`

`Extensible Markup Language (XML) 1.0
`
`7 of 28
`
`occur in their literal form; they need not (and cannot) be escaped using "&lt;" and "samp;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="l 0" ?>
`<greeting>Hello, world!</greeting>
`
`and so is this:
`
`<greeting>Hello, world!</greeting>
`
`The version number "l. o" should be used to indicate conformance to this version of this specification; it is an error for a
`document to use the value "l.o" if it does not conform to this version of this specification, ft is the intent of the XML
`working group to give later versions of this specification numbers other than "l.o", 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.
`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? Mise* (doctypedecl Mise* ?
`
`VersionNum ")
`
`XMLPecl : := '<?xml' Versionlnfo EncodingDecl? SDDecl? S? '?>'
`[23]
`[24] Versionlnfo : :=S 'version' Ecj (' VersionNum ' I
`Eq : .= S? '=1 S?
`[25]
`[26] VersionNum : := ([a-zA-Z0-9_.: I
`Mise : := Comment | PI | s
`
`[27]
`
`• - • > +
`
`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
`
`
`[28] doctypedecl : := '<!DOCTYPE' S Name (S ExternallD)? S? ('[' [28] doctypedecl :
`(markupdeel | PEReference | S)* ']' S?)? 1>'
`[29] markupdeel : := elementdecl | AttlistDecl | EntityDecl
`| NotationDecl | PI | Comment
`
`[ VC: Root Element Type 1
`
`f VC: Proper Declaration/PE
`Nesting ]
`
`[ WFC PEs in Internal
`Subset 1
`
`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, Attlistpecl, 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
`
`https://vveb.archive.Org/vveb/19980213212127/http:/vvvvwl3.w3.org/TR/REC-xml
`
`IBM-1010
`Page 10 of 31
`
`

`

`Extensible Markup Language (XML) 1.0
`
`8 of 28
`
`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
`
`130]
`
`extSubset :;- TextDecl? extSubsetDecl
`
`[31] extSubsetDecl ::= ( markupdecl | conditionalSect | PBReference [ 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:
`
`<?xml version="1.0"?>
`<!DOCTYPE greeting SYSTEM "hello.dtd">
`<greeting>Hello, world!</greeting>
`
`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
`
`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' j
`
`' no' )
`
`) | ( ' " '
`
`[VC: Standalone Document
`Declaration ]
`
`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 standaione="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, it, 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
`
`https://web.archive.org/web/19980213212127/http:/www 13 .w3 .org/TR/REC-xml
`
`IBM-1010
`Page 11 of 31
`
`

`

`Extensible Markup Language (XML) 1.0
`
`9 of 28
`
`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=1 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 applica