Valid XML documents

Valid XML documents
Prev	Chapter 2. Basics of XML	Next

We call a well-formatted XML document to a valid XML document if its logical structure and content is fit for the rules defined in the XML document (or in an external file attached to the XML document). These rules can be formulated with the help of:

DTD
XML Schema
Relax NG.

The goal of schema languages is validation, they has to describe the structure of a given class of XML documents. The validation is the job of the XML parser, it checks whether the document suites to the description of the schema. The inputs are the document and the schema, the output is a validation report and an optional Post-Schema Validated Infoset (PSVI) - which will be presented in the next chapter.

Schema languages give a toolkit to

define names for the identification of the document elements
control where the elements can appear in the document structure (forming the document model)
define which elements are optional and which are recurrent
assign default values to the attributes
...

Schema languages are similar to a firewall which protects the applications from the unexpected/uninterpretable formats and informations. An open firewall allows everything that is not forbidden ( for example Schematron), or a closed firewall which forbid everything that is not permitted ( like XML Schema).

A kind of classification of the schema languages

Rule-based languages – for example Schematron
Grammar-based – DTD, RELAX NG
Object-oriented languages – for example XML Schema

But these schema languages are not created in a such simple way and without any limitations. It could be seen at the list of XML technology families that several ISO standards can be listed for them. These include the Document Schema Definition Languages (DSDL, ISO-19757) too. The object of the standard is to create an extensible frame for validation-related tasks. During the validation various aspects can be checked:

structure: the structure of the elements and the attributes
content: the content of the attributes and text nodes
integrity: uniqueness test, links integrity
business rules: for example the relationship between the net price, gross price and VAT or even as complicated things as spell check.

This could hardly be solved with the help of only one language, therefore a combined use of different schema languages could be required. Typical example is the embedding of the Schematron rules into an XML Schema document. An XML schema language is the formalization of the constraints, the description of the rules or the description of the structure’s model. In many ways the schemas can be considered as a design tool.

XML dialects: DTD and XML Schema

Using schemas during the validation we can ensure that the content of the document complies with the expected rules and it is also easier to process it. Using different schemes we can validate differently. The XML 1.0 primer contains a tool to validate XML document’s structure, called DTD. The DTD (Document Type Definition) is a toolkit that helps us to define which element and attribute structures are valid inside the document. Additionally we can give a default value to the attributes, define reusable content and metadata as well.

DTD use a solid, formal syntax which shows us exactly which elements can occur in the given type of document and which content and property can an element have. In DTD we can declare entities, that can be used in the instances of the document. A simple example of DTD is shown below:

<!ELEMENT <!ELEMENT book (author, title, subtitle, publisher, (price|sold )?, ISBN?, zip code?, description?, keyword*  ) >
                            <!ELEMENT keyword ( #PCDATA ) >
                            <!ELEMENT description ( #PCDATA|introductory|body ) * >

Potentials provided by the DTD don’t meet the requirements of today’s XML processing applications. It is criticized mostly because of the followings:

non-XML syntax which does not provide the usage of the general XML processing tools, such as the XML parsers or XML stylesheets,
XML namespaces are not supported, which are unavoidable nowadays,
data types, that are typically available in SQL and programming languages are not supported,
there is no way of contextual declaration of the elements. (All elements can be declared only once.)

Many of the XML schema language have been created to correct these. The nowadays ”living” and widely used schema languages are the W3C XML Schema, RELAX NG and Schematron. While the first is a W3C recommendation, the last two are ISO standards. The most commonly used is the XML Schema but it also has some disadvantages:

The specification is very big which makes the implementation and understanding difficult.
The XML-based syntax leads to talkativeness in the schema definition that makes the XSD reading and writing harder.

The most important XML Schema elements

The XML Schema definition has to be created in a separate file, to which the same well-formatted rules apply as to an XML document which are followed by some additions:

the schema can contain only one root element, called schema,
all elements and attributes used in the schema have to belong to the "http://www.w3.org/2001/XMLSchema" namespace, thus indicating that this is an XML Schema, most commonly used as xsd or xs prefix.

The most important attribute of the schema element is the elementFormDefault which specifies that the element must be qualified or it could be omitted. The same is true for the attributes (attributeFormDefault) as well. Based on the experience the best thing we can do, that we work through with qualified names, so we won’t be surprised by any processors.

The building blocks of the XML Schema documents are the elements. The elements store the data and define the structure of the document. Elements can be defined in the XML Schema in the following way:

<xs:element name="name" type="xs:string" default="unknown" />

example - Defining a simple item

The name attribute is required, it must appear in the document. The type attribute determines the type of value that an element can be contain. There are predefined types which are almost similar to the ones met in the Java language (for example xs:integer, xs:string, xs:boolean), but we can define own types as well. We can further refine the available value of the element with the default and the fixed property. If we do not specify any value in the document, the application will use the default value. If the fixed is set, you can use only this value for the element.

You can specify cardinality, which tells the maximum number of times the element may occur in a given position. The minOccurs and maxOccurs attributes specify the minimum and the maximum occurrences. The default values for both are 1.

<xs:element name="address" type="xs:string" minOccurs="1" maxOccurs="unbounded">

Example – Enter the cardinality of an element.

It is possible to create your own type, so that your own type is derived from the subtypes.

<xsd:element name="EV">
	<xsd:simpleType>
		<xsd:restriction base="xsd:gYear">
			<xsd:minInclusive value="1954"/>
			<xsd:maxInclusive value="2003"/>
		</xsd:restriction>
	</xsd:simpleType>
</xsd:element>

The derivation is performed by the restriction keyword. So that we give the type to the base feature of the restriction element which is used for the derivation in order to get your own type. You can specify the constraints of your own type through the children of the restriction element. There are no limit for the constraints, it offers option for anything which is superseded by the possibility of regular expressions.

You can define the structure with complex element types. There are two groups of these: simple content and complex content based. Both of them may have attributes but only the complex one may obtain child element. You can see below a definition of a simple content based type:

<xs:complexType name="address">
	<xs:simpleContent>
		<xs:attribute name="city" type="xs:string" /> 
	</xs:simpleContent>
</xs:complexType>

Example – The definition of a simple content based type

Let’s see the definition of a complex content based type:

<xs:complexType name="address">
	<xs:complexContent>
		<xs:sequence>
			<xs:element name="street" type="xs:string"/>
			<xs:element name="streetnumber" type="xs:integer"/>
		</xs:sequence> 
	</xs:complexContent>
</xs:complexType>

Example – The definition of a complex content based type element

At the complex element type you have to define a compositor. This will specify that how to manage the child element. There are three of them:

sequence
choice
all

The sequence method will recommend that the document has to show the children elements as they appear in the scheme. In case of all the order of the elements have no significance. If this option is choice, then only one child element can be shown from the listed ones.

The complex types are recyclable, if they are independent from any elements, they are like global definitions. If you define a new type, you have to give a name for it.

Finally we discuss the references, which make the management of redundant data easier because it lowers their numbers. The reference method can be performed by the “ID” and “IDREF” types in the scheme. The “ID” type is used to identify an element or attribute and you can refer to them with the “IDREF” type. These identifiers must be unique in the whole document. If you try to use an already existing identifier or refer to a non-existing one, the document will be invalid. The identifier is a “NCName” type, whose first character element must be a letter or underline, the rest is up to the programmer.

The following two types are part of a hospital system scheme, which represent a link between a sick-bed and the patient admissions.

<xsd:complexType name="Bed">
	<xsd:sequence />
	<xsd:attribute name="id" type="xsd:ID" use="required" />
	<xsd:attribute name="number" type="xsd:string" use="required" />
</xsd:complexType>

Example - Sick-bed type

<xsd:complexType name="AdmissionInformation">
	<xsd:sequence>
		<xsd:element name="admissionDate" type="xsd:dateTime" />
		<xsd:element name="endDate" type="xsd:dateTime" minOccurs="0" />
	</xsd:sequence>
	<xsd:attribute name="bedRef" type="xsd:IDREF" use="optional"/>
	<xsd:attribute name="medicalAttendantRef" type="xsd:IDREF" use="required" />
	<xsd:attribute name="end" type="xsd:boolean" use="optional" />
	<xsd:attribute name="recovered" type="xsd:boolean" use="optional" />
</xsd:complexType>

Example - Patient admissions type

The “Bed” type has two attributes: an identifier, “id”, and a bed number, “number”. The “AdmissionInformaton” is more complex and the most important that it has two “IDREF” attributes: one that refers to the patient’s bed, “bedRef”, and one, which refers to the doctor, “medicalAttendantRef”.