• Tutorial
• Examples
• Test
• Exercise

4.2.1. XML Declaration #

An XML document is introduced by the XML declaration:

The question mark ? in the XML declaration signals that this is a processing instruction. The following bits state that what follows is XML which complies with version 1.0 of the recommendation and that the used character encoding is UTF-8 or Unicode. An XML declaration is optional, but can only appear as the first content of an XML file.

4.2.2. Elements and Attributes #

The two-paragraph document above is an example of an XML document, representing both information and meta-information. Information (plain text) is contained in XML elements, delimited by start tags (e.g., <document>) and end tags (e.g., </document>). Additional information to these XML elements can be given in attributes, consisting of a name (e.g., @number) and a value (e.g., "1"). Attributes can only occur within the start tag of an element. XML comments are delimited by start markers (<!--) and end markers (-->). Everything inside comments is ignored by XML processing software: it is said to be “commented out.”

4.2.3. Entity References #

Entity references are predefined strings of data that a parser must resolve before parsing the XML document.

Entity references may be useful in a number of cases:

• representing character data which cannot easily be keyboarded or which is illegal in XML because some characters are reserved
• escaping reserved characters in XML
• providing “boilerplate text,” that is text which is or can be reused in new contexts or applications

An entity reference starts with an ampersand & and closes with a semicolon ;. The entity name is the string between these two symbols. For instance, the entity reference for the “less than” sign < is &lt;. The entity reference for the ampersand is &amp;.

Not all computers necessarily support the Unicode encoding scheme XML works with. Portability of individual characters from the Unicode system, however, is supported by entity references that refer to their numeric or hexadecimal notation. For example, the character ø is represented within an XML document as the Unicode character with hexadecimal value 00F8 and decimal value 0248. For exporting an XML document containing this character, it may be represented with the corresponding character reference &#x00F8; or &#0248; respectively, with the x indicating that what follows is a hexadecimal value. References of this type do not need to be predefined, since the underlying character encoding for XML is always the same.

For legibility purposes, however, it is also possible to refer to this character by use of a mnemonic name, such as oslash, provided that each such name is mapped to the required Unicode value by means of an ENTITY declaration.

The ENTITY declaration uses a non-XML syntax inherited from SGML and starts with an opening delimiter < followed by an exclamation mark ! signalling that this is a declaration. The keyword ENTITY names that an entity is being declared here. What follows next is the entity name - here the mnemonic name &oslash; - for which a declaration is given and the declaration itself inside quotation marks. In this example, it is the hexadecimal value of the character.

The same character can also be declared in the following ways:

Character entities must also be used in XML to escape the “less than” sign < and the ampersand & which are illegal because the XML parser could mistake them for markup.

Entities are not only capable to refer to character declarations but can also refer to strings of text with an unlimited extent. This way, repetitive keying of repeated information can be avoided (aka string substitution), or standard expressions or formulae can be kept up to date. The first is useful, for instance, for the expansion of &TBE; to “TEI by Example” before the test is validated. This corresponding ENTITY declaration is as follows:

The second is used in contracts, books of laws, etc. in which updating would otherwise mean the complete re-keying of the same (extensive) string of text. For example, the expression: This contract is concluded between &party1; and &party2; for the duration of 10 years starting from &date; in legal texts can be updated simply by changing the value of the ENTITY declarations:

The substitution of the entities by their values in the given example results in the following expression: This contract is concluded between Rev Knyff and Lt Rosen for the duration of 10 years starting from 2007-01-01.

ENTITY declarations are placed inside a DOCTYPE declaration which follows the XML declaration at the beginning of the XML document:

The DOCTYPE declaration starts with the opening delimiter <! which is followed by the keyword DOCTYPE. Next comes the name of the root element of the document. In the case of a TEI document, this will be TEI. The entity references which must be interpreted by the XML processor are put inside square brackets. An XML parser encountering this DOCTYPE declaration will expand the entities with the values given in the ENTITY declaration before the document itself is validated.

4.2.4. (P)CDATA #

All text in an XML document will normally be parsed by a parser. When an XML element is parsed, the text between the XML tags is also parsed. The parser does that because XML elements can nest as in the following example:

The XML parser will break this string up into an element <paragraph> with a subelements <title>. Text data that will be parsed by an XML parser is called parsed character data or PCDATA.

An XML document often contains data which need not be parsed by an XML parser. For instance, characters like < and & are illegal in XML elements because the parser will interpret them as the beginning of new elements or the beginning of an entity reference which will result in an error message. Therefore, these characters can be escaped by the use of the entity references &lt; and &amp;. When programming or scripting code (such as Javascript, which contains many occurrences of &lt; and &amp;) is included in an XML document, it should not be parsed by the XML parser. We can avoid this by treating it as unparsed character data or CDATA in the document:

A CDATA section starts with <![CDATA[ and ends with ]]>. Everything inside a CDATA section is treated as plain text by the parser.