Li Tak Sing COMPS311F

XML Schemas XML Schema is a more powerful alternative to DTD to describe XML document structures. The XML Schema language is also referred to as XML Schema Definition (XSD). You have seen the DTD for the employee list.

XML schemas for employee-list

XML schemas for employee-list

The root element of an XML Schema is just schema. It must be specified with the namespace of " By convention, we use the prefix of xs or xsd though technically we could choose other prefixes, for example a meaningless prefix abc. The XML Schema will still be correct if we change all occurrences of xs to abc.

Referring to an XSD file You have learned that the inclusion of the following DOCTYPE declaration in an XML document will validate it against employee- list.dtd. For validation of an XML document against an XSD, you will remove the DOCTYPE declaration and modify the start tag of the root element with two added attributes as follows. The xmlns:xsi attribute indicates that this XML document should be validated against an XML Schema. The xsi:noNamespaceSchemaLocation attribute specifies the file name of the schema and its location. Since no path is specified, the schema file is assumed to be in the same directory as the XML file being validated. As can be seen below: The namespace is now bound to xsi which is the standard prefix for XML Schema Instance.

Simple elements in XSD A simple XML element is one that does not contain any other elements. Its content can be one of the few dozens of built-in data types. The more popular ones are: string, decimal, integer, boolean, date and time. The name element is a simple element. For example: This makes use of the optional attributes minOccurs and maxOccurs to specify the minimum and maximum number of occurrences in its parent (enclosing) element. Since both attributes are set to one, the name element must occur exactly once in the enclosing employee element.

Value restrictions by range The hours element is defined with the restriction element available from XML Schema. The base type decimal is restricted to the minimum value of 0 and maximum value of 60 inclusively. This lower bound of zero is obvious because it is impossible to work negative number of hours. The upper bound of sixty could be due to the company policy or labour regulations.

Value restrictions by range The XSD specification is vastly better that the earlier DTD specification which does not consider non-numeric values in hours as errors.

Value restrictions by enumeration There are other forms of value restrictions. Enumeration allows you to restrict an element to a list of possible values. The fruit element is defined below to have one of three possible values: Apple, Banana and Orange.

Value restrictions by pattern More advanced restrictions are specified with the pattern element. The direction element is restricted to one of the directions: north, south, east and west respectively denoted by their first characters n, s, e and w. Even the base type is specified as a string, the direction element can only have one character because there is only one pair of square brackets in the pattern. The square brackets specify the four allowed values: n, s, e and w.

Value restrictions by pattern

Value restrictions by pattern The following definition allows 2-character strings. The first character is a lower case or upper case character while the second character is a decimal digit. Values allowed include A1, a1, B3 but not BB.

Suppose we want to allow strings like r2d2, H5N1, H1N1 and c9L3k4. The strings can hold non-zero repetitions of the 2-character string pattern that we defined above. We could put the original pattern in brackets and add a trailing + for non-zero repetitions as follows. If we also allow empty strings, we will replace + with *.

Whitespace processing restrictions A whitespace character is one of line feed, tab, space and carriage return. Inside a restriction element, you can have a whiteSpace element. The attribute value of preserve is for not changing any whitespace characters, replace for replacing whitespace characters with space characters, and collapse for replacing consecutive whitespace characters with a single space character. The following is an example.

Restrictions on string length You can restrict the length of a string to a fixed number. In this example, a password must have 8 characters.

Restrictions on string length You can also restrict the length of a string to a range. In the following example, a password must have at least 6 characters and a maximum of 10 characters.

Complex elements in XSD An XML element is complex if it contains attributes or other elements.

Sequence We may have a student element that contains the elements of firstname and lastname as follows: Peter Wong

It could be defined as a sequence in a complex type.

Note that if the two child elements appear in the XML document in a different order, for example lastname before firstname as follows, the validation will fail. In other words, ordering is crucial in sequences. Wong Peter

Attributes If an element can have attributes, there must be attribute elements defined within its complexType attribute. Suppose we have a student element. Its XML Schema definition would look like this.

Text with attributes In XML Schema, we can use the extension element to define attributes for any simpleType or complexType element. Consider the following element to express shoe sizes. 9 Its XSD definition would look like this.

However shoe sizes are not standardized across countries. For example, the UK shoe size 8 is slightly larger than the US shoe size 8. In a shoe catalogue, it may be necessary to indicate the country for which the size number applies. 9 We can define the XML Schema with the extension element to hold the integer representing the shoe size. Within the extension element, we have the attribute element for the country. To keep our schema simple, we chose not to represent half size.

Texts mixed with other elements In its simplest form, an element may contain just texts as follows. Your buy order of 400 shares of HSBC has been executed on Perhaps certain parts of the texts have special meaning. You can turn special parts into elements to facilitate processing. The following element sms has been enhanced by making the quantity of shares, stock name and date into elements. Your buy order of 400 shares of HSBC has been executed on

You can define the corresponding complexType element by setting its mixed attribute to true.

Unspecific order in a complex type Suppose we don’t care if the first name or the last name appears first in a student element. Peter Wong Wong Peter

In that case, in place of the sequence element, we can use the all element to accept any order for firstname and lastname.

Choice in a complex type Suppose you only want to contact customers by their addresses or phone numbers but not both. The following are the contact information for two different customers

The two alternative customer elements are expressed with the choice element as follows.

Named types for reuse Suppose you want to have an element to capture someone’s favourite fruit, as follows: Apple This can also be enforced as follows which also allows you to specific which fruit, here it would be banana and orange.

If we have elements other than myfruit that make use of this enumeration of Apple, Banana and Orange, we can define a type called fruitType. This will result in a more readable XML Schema without the risk of different usages of the enumeration to get out of step when for example Coconut is added to the existing fruits. Changing the original element definition to use a named type is trivial. First, you add the type attribute to the element with the new type name.

Second, you add the name attribute to the simpleType or complexType.

However, where can you place this named type definition in the XSD file? You can put it right below its first use. Alternatively, you can group all the named type definitions together and place them right after xs:schema’s start tag or just before its end tag. Good use of named types can make an XSD file more readable and maintainable.

elementFormDefault and attributeFormDefault In the sample XML Schemas we have presented so far, some names have prefixes and some don’t. You are probably confused when you should use a prefix. In the schema element, you can use two attributes to control this. Attribute elementFormDefault controls whether prefixes are required for element names. Likewise attributeFormDefault controls whether prefixes are required for attribute names. We use the value qualified for prefixes required and the value unqualified for prefixes not required. The sample code that we have been using has prefixes for elements but not for attributes as indicated below.

The default values of both are unqualified. Therefore removing attributeFormDefault as follows will have the same meaning.

In case the two attributes are set to qualified, we can still avoid the use of prefixes with a default namespace. Consider the following XML schema saved in the file employee.xsd.

The following XML document can be successfully validated against it. Oliver Au

The xsi:schemaLocation attribute specifies two URI references separated by white space. The first value here is a namespace. The second value employee.xsd gives a hint to the location of the schema document. If we had specified elementFormDefault attribute as qualified.

The validation will fail. The XML document must be modified as follows. Note the required prefixes added to the name, and hireDate elements. Oliver Au