XML Document Layout and Syntax
An XML document contains a hierarchy of data values wrapped inside XML elements
and includes various other entries to assist in processing this information. The
data structure and processing entries must conform to exacting rules.
Standards and specifications for designing XML documents are maintained by the
World Wide Web Consortium (W3C) and can be found
here. These recommendations
give the structural and syntactical rules for creating XML documents
and standards for testing their validity.
An XML document contains two major sections -- the prolog
and data structure sections. The prolog identifies the document
as an XML document and includes other optional entries for specialized processing.
The data structure section includes the hierarchy of data elements representing
the document's information content.
The prolog section of an XML document contains three optional elements:
- XML declaration
- Processing instruction
- Document type definition
The XML Declaration
The XML declaration, if included, must appear as the first line
of the document. The declaration consists of a mandatory version number, an
optional encoding declaration specifying the character set used, and an optional
indication of the stand-alone nature of the document.
[encoding="UTF-8"] [standalone="yes"] ?>
The current version is 1.0 and must be included. An encoding declaration is needed
only when using a non-Latin (non-English) character set. The default character
set is UTF-8 and does not need to be coded. The standalone="no" attribute is
required when reference is made to an external file containing additional
declarations for the current document (see "Document Type Definition" below).
The default value is standalone="yes" (this is a stand-alone document) and the
attribute can be omitted.
An XML declaration is optional, but it is always a good idea to include it since
W3C recommendations state that a "well-formed" document begins with an XML
A processing instruction is a reference to a supporting
document containing processing instructions relevent to the XML document.
Most likely, this processing instruction refers to an external style sheet
used to transform the document in some fashion, normally to format the XML
data content for Web page display. A processing instruction that links to an
external style sheet appears as shown below.
Working with XML style sheets to perform transformations of XML documents
into Web pages and into other XML documents is considered later in these tutorials.
Document Type Definition
A document type (DOCTYPE) declaration is required if the XML document is to be
validated against a Document Type Definition (DTD).
A DTD is a set of rules for interpreting the data elements and their relationships.
For example, DTD entries can indicate proper names and valid data types for
data elements in the document. The general formats for DOCTYPE declarations are
> ... ]>
An internal DTD can be coded as part of the XML document, or an external
DTD can be coded in a separate document. If DTD specifications are in an external
document linked by the url, then the attribute standalone="no" must be
coded in the XML declaration. An XML document that satisfies DTD specifications
is said to be "valid" in addition to being well-formed. DTD validation is considered
later in these tutorials.
The Data Section
Following the prolog is the XML data structure for the information content of the
document. Appearing here are the XML tags signifying the data nodes and data
elements that compose the hierarchy of information. Although there is great
flexibility in naming and organization XML tags, there are fixed rules for doing
One of these syntactical rules is that all XML elements must have opening and
closing tags. This rule can be followed in two ways.
For XML elements that enclose data or enclose child elements there must be an
opening tag along with a paired closing tag. These tags are in the
where the closing tag includes the forward slash character (/) preceding the
tag name. You are probably familiar with this syntax from XHTML where, for
example, a paragraph is enclosed inside
For XML elements that do not enclose data or child elements a single start/end
tag can be used. These empty tags are in the format,
where the single tag includes a forward slash following the tag name.
Again, you are familiar with this format in XHTML through the
<br/> tag and other similar non-paired tags. Empty tags
are often used as "markers" to indicate a point in the data structure where
special processing is to take place. It is unlikely, though, that you will use
empty tags in the normal course of XML data structuring, where elements nearly
always enclose other elements.
XML tag names are case sensitive. You are free to use upper- or lower-case
characters in composing your tags; however, you must be consistent in their use.
<MyTag> is an entirely different identifier from
<MYTAG>. By convention, tag
names use lower-case characters.
XML tag names can begin with an alphabetic character or the underscore ( _ )
character and be composed of alphabetic, numeric, and other characters.
They cannot begin with the characters "xml" nor can they include blank spaces.
You should not use mathematical symbols or decimal points (periods) in the names.
Most often you will use common, meaningful names for your tags, names that are
suggestive of the data content.
At the lowest levels of the XML hierarchy, tags enclose and identify data values.
On some occasions the data themselves may include the special "<" and ">"
characters that signify tags. For example, if a data value includes an XHTML tag
as in the following element,
<paragraph>An XHTML page begins with the <html> tag....</paragraph>
you cannot directly code "<" and ">" characters surrounding "html". These
characters are interpreted as XML code by the parser and their use results in an
XML document that is not well formed. A parsing error results. Instead,
"<" and ">" symbols used as data values must be replaced by their character codes
<paragraph>An XHTML page begins with the
The "&" sign also has special meaning in XML. If it appears as data inside XML
tags it must be replaced by its character code
If there is an extensive amount of character data that should not be interpreted as
XML code, this text can be enclosed inside a CDATA section of the
XML document. This section is identified and enclosed by the special strings
...text containing special characters
For example, the following XML
<code> element includes XHTML code
whose "<" and ">" characters should not be interpreted as XML symbols.
The following tags appear at the beginning of XHTML pages:
XML tags can have attributes, used in much the same way as XHTML
tag attributes. Attributes are normally considered to be "identity" information,
not primary data values like those enclosed inside named tags. Attribute values
must be enclosed in quotes, either double quotes ("") or single quotes ('').
Opposite quotation marks must be used if the attribute value itself includes a
double quote or apostrophe.
Whether a data value is coded as an attribute or a data element is left to the
discretion of the data designer. Consider, for instance, the following
<Employee> node taken from the preceding
<Personnel> data structure.
An alternative way to code this structure is to use the SSN value as an
attribute of the
<Employee> element rather than as a separate
data element. Of course, all other
<Employee> nodes in the
document would need to include this same attribute to remain consistent.
Both of the node examples are equivalent in terms of the data values they
represent. The only difference is that the SSN attribute requires additional
processing to extract its value whereas the SSN child node can be processed in
the same manner as the other child nodes.
As a general rule it is best to avoid use of attributes unless there is no better
way to designate or assign values to data elements. If a data value is important
enough to be included in the data structure, then it is probably deserving of its
own data element.
XML data are enclosed inside opening and closing tag pairs which must be properly
nested one inside another. That is, inner tags must be closed before the enclosing
set of outer tags is closed.
The above example points out that you can choose to arrange your data within any
preferred parent/child relationships. Here, the FirstName and LastName elements
have been nested inside a Name parent element. The reason for doing this is to make
it more convenient to extract both values through the single Name element rather
than having to extract them individually. The way in which you arrange your data will
depend to a large extent on how you intend to access it. There are no formal rules
for when or when not to enclose elements inside a parent identifier element so long
as opening and closing tags are properly paired.
Comments can be placed anywhere in the XML document to provide commentary about
the document and its sections. Comment tags also can appear around document
sections to disable them during debugging. XML comments use the same syntax as
<!-- comment -->
Well Formed and Valid Documents
XML documents that meet the above syntactical rules are said to be
well formed, meaning that the XML parser will not find error with
their arrangement and coding. If a document is not well formed, the parser reports
the error and ceases its evaluation of the document.
A document that is well formed, however, may not be valid. For
instance, you may have inadvertently entered non-numeric characters into an
element that is supposed to contain only numbers; or, perhaps you inadvertently
left out a child element in one of the parent nodes. The way in which you catch
an invalid structure or invalid data is by providing a Document Type Definition
(DTD) against which the document can be validated. Validating XML documents is
reserved for discussion later in these tutorials.
An XML document must be well formed in order to be evaluated by the parser.
The document may be, but is not required to be, valid. An invalid document
can be evaluated correctly by the parser although incorrect processing results may
be produced. Throughout most of these tutorials consideration is given only to
well-formed documents, saving the complications of data validation for a later
The Document Object Model
There are two primary ways to access and process data residing in an XML file.
Stream-based methods input the XML structure as a sequence of
elements and data values arriving one at a time. It is up to the processing
program to bring order and structure to the individual elements and to handle
them as components of a larger hierarchy. Stream-based methods are often used
for fast access to individual components of interest, to extract particular
data elements or to duplicate a structure through simple read/write methods.
Stream-based methods are applicable only to server processing of XML documents;
there are no equivalent browser methods owing primarily to the fact that browsers
do not permit writing files to the local computer.
Memory-based methods input and retain the entire XML document
inside computer memory, making the full document accessible at one time. These
methods provide direct access to any parent or child element, or their combinations,
without having to read sequentially through the structure. Most XML processing is
through these memory-resident methods which have equivalents in the browser and on
Access to the in-memory document is through the
Document Object Model (DOM). The Document Object Model is the
application programming interface (API) to an XML document. The DOM provides a
rich set of properties and methods for locating, extracting, and processing data
elements based upon the overall structure of the document. Standards for DOM
processing are maintained by the W3C and are available at
A Document Object Model is available in modern browsers for browser-side processing
of XML documents. As meantioned previously, the MSXML parser is built into Internet
Explorer. This parser recognizes XML files linked through a URL and builds a
memory-resident document tree from the identified data elements. By default, this
tree is displayed in the browser as an expandable-contractable list of data elements.
However, the document also can be processed in one of two ways. The document can be
associated with a style sheet in order to select and format elements for display as
a Web page using the XHTML markup language. In addition, the document can be
tree and apply specialized processing to data elements. These methods are used to
offload XML processing from the server to the browser. Both, though, make use of
the properties and methods of the local Document Object Model to effect their
A comparable DOM is available for server-side processing. Through various .NET
software classes an XML document is loaded into memory, with DOM properties
and methods accessible through the Visual Basic language employed on ASP.NET
pages. In this case, XML data can be read from and written to server files, or
the document tree can be traversed with server scripts to perform all manner of
information processing, similar in scope to processing methods used for standard
files and databases. In fact, XML data structures become viable alternatives to
files and databases as primary data stores for organizational information. Not
only that, but XML data files can be easily exchanged between diverse computer
systems owing to their standard formats and transmission protocols.
Most of the effort in learning XML is in learning the properties and methods of
the XML DOM to manipulate data values contained in XML documents. The focus of
these tutorials is on the XML Document Object Model and its application programming
interface for both browser and server processing of XML documents.