Tài liệu Module 8: Validating XML Data Using Schemas doc

This section begins by differentiating between the structure of an XML document that is, what elements and attributes are allowed where and the semantics of an XML document for example,

Schemas

to represent any real individual, company, product, or event, unless otherwise noted Complying with all applicable copyright laws is the responsibility of the user No part of this document may

be reproduced or transmitted in any form or by any means, electronic or mechanical, for any purpose, without the express written permission of Microsoft Corporation If, however, your only means of access is electronic, permission to print one copy is hereby granted

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property

 2000 Microsoft Corporation All rights reserved

Microsoft, MSDN, MS-DOS, PowerPoint, and Windows are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A and/or other countries

The names of companies, products, people, characters, and/or data mentioned herein are fictitious and are in no way intended to represent any real individual, company, product, or event, unless otherwise noted

Other product and company names mentioned herein may be the trademarks of their respective owners

Program Manager: Steve Merrill

Instructional Designers: Sangeeta Nair (NIIT), Vijayalakshmi Narayanaswamy (NIIT)

Subject Matter Experts: Andy Olsen (QA Training), Andy Longshaw (Content Masters)

Content Lead: Janet Robinson

Graphic Artist: Scott Serna (Creative Assets)

Media Management: David Mahlmann

Media Production: Dean Connolly (Art Source), Timothy Demmon (:timebomb Media)

Editing Manager: Jennifer Linn

Editor: Dennis Rae (Wasser)

Production Manager: Miracle Davis

Print Coordinator: Marlene Lambert (Online Training Solutions, Inc)

Build Manager: Julie Challenger

Build Coordinator: Jenny Boe

Test Lead: Eric Myers

Manufacturing Manager: John Williams

Group Product Manager: Steve Elston

Instructor Notes

This module describes how to create and use Microsoft XML schemas to validate XML documents Students have already been introduced to the concept

of validation in Module 2, “Overview of XML Technologies.” In that module,

we introduced the need for validation, showed the syntax of simple Document Type Definitions (DTDs), and briefly mentioned the use of XML schemas as the preferred alternative to DTDs

In this module, students are now shown the full syntax for XML schemas, as supported by Microsoft The Microsoft standard for XML schemas is also referred to as XDR (XML Data Reduced), and is different in several respects to the schema definition in the W3C draft standard

Once the XML schema syntax has been introduced, this module describes how

an XML schema can be applied to an XML document received at the server You should impress upon students the need to perform validation of XML data

at the server whenever it is received from an unknown client

After completing this module, students will be able to:

! Describe when validation is needed

! Create an XML schema

! Validate an XML document by using an XML schema

! Apply an XML schema to an XML document, both statically and dynamically

Materials and Preparation

This section provides you with the required materials and preparation tasks that you need to teach this module

Required Materials

To teach this module, you need the following materials:

! Microsoft PowerPoint® file 1905a_08.ppt

! Module 8, “Validating XML Data Using Schemas”

! Lab 8, “Validating XML Data Using Schemas”

Preparation Tasks

To prepare for this module, you should:

! Read all of the materials for this module

! Complete the labs

Due to the length of the answers to the labs for this course, we were unable

to include them in the Delivery Guide Please see Appendix A and the Student CD for the lab answers

! Read the working draft specification for XML schemas on the W3C Web site at http://www.w3.org

! Read the latest information about Microsoft’s support for XML schemas at

Module Strategy

Use the following strategies to present this module:

! The Need for Validation This section sets the scene for the rest of the module — students need to appreciate the need for validation before looking at the details This section begins by differentiating between the structure of an XML document (that

is, what elements and attributes are allowed where) and the semantics of an XML document (for example, what value an <address> element can have) You should emphasize that validation can help to identify what data is allowed, but it does not specify how you should process that data

You should also spend some time describing why a document might have an invalid structure, whether due to programming error, malicious or accidental corruption, or different versions of a document being used at the client and server

! Writing an XML Schema This is the main section of the module It covers all the syntax for defining XML schemas, and how to apply an XML schema to a static XML document

You might want to compare <ElementType> and <AttributeType> with type definitions in other programming languages (for example, typedef in

Microsoft Visual C/C++) Also make sure that students understand the difference between <ElementType> and <element type= >; the former introduces a new type, the latter indicates a usage of that type The same issue arises with <AttributeType> and <attribute type= >

In addition to pointing out the syntax, you should highlight the following key differences between XML schemas and DTDs:

• XML schemas allow an open content model

• XML schemas allow data types to be specified

• XML schemas are extensible

• XML schemas are applied to XML elements, rather than being applied

to an entire document (as is the case with DTDs)

• XML schemas are themselves XML documents This allows for some sophisticated programming techniques, such as XML schemas that are definable and modifiable at run time

! Extending an XML Schema Another key difference between XML schemas and DTDs is that XML schemas allow you to add elements and attributes to the XML document using the schema

This would be useful if every XML document needed this new information Rather than adding the additional elements and attributes to every

document, you can add them in one place (the schema), and all XML documents using that schema will have the new elements and attributes

! Validating XML in a Client/Server Environment

In this section, we show how to apply an XML schema to an XML document in a more realistic client/server environment Initially, we show how the client can attach an XML schema before sending the document to

the server In this scenario, when the document is loaded into an XMLDOM

object at the server, the document is automatically validated (as long as the

validateOnParse flag is set to True, which is the default)

However, when the server loads the XML document, it has no way of knowing in advance whether an XML schema is present Only when the document has been loaded can the server check for the XML schema If there is no XML schema attached, the server can programmatically apply the XML schema, then load the XML document (plus the XML schema)

into a new XMLDOM object to enable the document to be validated

At the server, you cannot reference an external XML schema by specifying

a URL in the xmlns attribute — you can only use schemas found on the local

Web server For more information, search for the Knowledge Base article

#Q235344: “FIX: DTDs and Schemas Not Resolved When Using loadXML Method” on the MSDN™ Web site at http://msdn.microsoft.com

! Lab 8: Validating XML Data Using Schemas This is the final lab in the course, and completes the LitWare Books Web application By this point in the course, students should have a good grasp

of the application and be comfortable with the flow of XML data between the client and the server

In this lab, students write a new XML schema to validate the XML customer order submitted from the client during checkout

The first exercise takes the majority of the allocated time for this lab In this exercise, students write the XML schema and test it against a static XML document to ensure that the XML schema is correct

In the second exercise, students use the XML schema in the context of the LitWare Books Web application Specifically, when CustomerOrder.asp receives an XML data packet representing a customer order, the ASP applies the XML schema and tests the document for validity A suitable error message, in XML format, is returned if the XML data is invalid

# Overview

One of the key aims of XML is to facilitate the open exchange of information between applications and organizations Clearly, this is only possible if the structure or the format of these XML documents can be agreed upon and defined

The proper format of an XML document may be defined in either an XML schema or a Document Type Definition (DTD) Once defined, the XML schema

or DTD can be used to validate the contents of an XML document

XML schemas offer several technical advantages over DTDs This module describes how to create an XML schema, and shows you how to apply the schema to an XML document You will also learn how to apply an XML schema to an XML document dynamically when the document is received at the Web server

After completing this module, you will be able to:

! Describe when validation is needed

! Create an XML schema

! Validate an XML document by using an XML schema

! Apply an XML schema to an XML document, both statically and dynamically

In this module, you will learn

how to use XML schemas to

# The Need for Validation

In this section, you will learn about the need for validation when XML documents are exchanged within an application, between applications in the same organization, and across organizational boundaries

This section highlights what can and cannot be achieved by using XML schemas or DTDs to validate XML documents, and also describes some of the typical causes of invalid XML documents

Slide Objective

To provide an overview of

the topics in this section

Lead-in

This section introduces the

need for validation of XML

data, and describes the

benefits of using XML

schemas rather than DTDs

to achieve validation

What Can Be Validated: Structure

agree on the structure of the documents

documents

Elements

What elements are allowed?

What child elements are required or optional?

Is the order or number of child elements important?

What content type is allowed?

Attributes

What attributes are required or optional?

What are the data types of the attributes?

Are there any meaningful default values?

XML schemas and DTDs define the element and attribute types that are allowed in an XML document XML schemas allow a more rigorous definition

of document structure than DTDs

The structure rules should include the following details about elements in the XML document:

! What element types are recognized?

! Which elements are child elements of other elements?

! How many child elements are allowed?

! Is the sequence of child elements significant? If so, what is the correct sequence?

! What type of content is allowed for each element?

The structure rules should also include the following details about attributes:

! What attribute types are recognized?

! What attributes are required for each element type?

! Are the attributes required or optional?

! What is the data type of each attribute?

! Is there a restricted set of values that can be used for each attribute?

! Is there a default value for each attribute?

were introduced earlier in

the course as a means of

defining the format of XML

documents

What Cannot Be Validated: Semantics

validating its semantics

structure, not semantics

<postal-address>12 Main Street</postal-address>

Without this understanding of the semantics, it is quite possible to create an XML document that complies with the expected format but is still misleading

Example of ambiguous semantics

Consider a situation where an XML schema or DTD specifies an <address> element for an XML document There is scope for confusion and

misinterpretation here — “address” might mean a postal address, an e-mail address, or even a URL for a Web site

XML schemas and DTDs can verify that the XML document contains an

<address> element, but cannot determine the correct type of the address supplied

The easiest solution is to define different XML element types for each type of address, as in the following example:

<postal-address>12 Main Street</postal-address>

A slight variation on this theme might be to use an <address> element for each type of address as before, but to add an attribute to describe what type of address is being represented:

<address type="postal">12 Main Street</address>

<address type="email">jdoe@microsoft.com</address>

This approach preserves the semantic differences between the different address types, but prevents the proliferation of new element types that might clutter up

an XML document

Detecting Incorrect Documents Using Validation

Validating XML documents involves the following steps

Defining an XML schema or DTD

The first step in validating an XML document is to define an XML schema or DTD for that type of document The XML schema or DTD defines the structure for all documents of the same type

For example, the LitWare Books Web application generates many XML documents with <booklist> information Each XML document contains a different list of books, but the structure of each document is the same

Therefore, it is only necessary to define a single XML schema or DTD, which applies to all of these documents

Applying XML schemas and DTDs

An XML schema or DTD can be applied to an XML document when it is created by the document author Any recipient of the XML document will have immediate access to the XML schema or DTD for that document, and therefore will be able to validate the document

Alternatively, the document author can choose to omit the XML schema or DTD initially Recipients can then apply the XML schema or DTD themselves when the document is received This entails more work for the recipient, but allows the recipient to be sure that the correct XML schema or DTD is applied This is the preferred method in a client/server environment because a server that receives XML data from clients cannot be sure that an XML schema or DTD has been applied beforehand

Slide Objective

To describe the process for

validating XML documents

Lead-in

There are certain tasks you

must undertake if you want

your XML documents to be

validated when they are

loaded

Enabling the parser

When an XML schema or DTD is applied to an XML document, validating parsers will check the structure of the document as it is loaded Any validation errors will cause the document loader to abort

You can perform validation at either the client or the server For example, the client might wish to confirm that an XML document received from the server is valid Conversely, the server might need to validate XML posted from the client Depending on where you wish to perform validation, you can write client-side script or server-side script to test the outcome of the validation operation, and respond accordingly

Demonstration: Validating XML Data

In this demonstration, you will see how to install a simple validation utility that can be integrated with Internet Explorer 5.0 to provide immediate feedback on the validity of an XML document loaded in Internet Explorer 5.0

The validation utility is available on the Student CD-ROM in the folder

\Sampapps\xml diagnostics\xml validation

! To install the XML Validation utility

• On the Student CD-ROM, right-click the file msxmlval.inf in the folder

\Sampapps\xml diagnostics\xml validation, and then click Install

Slide Objective

To show how to install a

validation utility that can be

integrated with Internet

Explorer 5.0 in order to test

the validity of XML

documents

Lead-in

Microsoft provides a simple

tool that can be integrated

with Internet Explorer 5.0,

so that you can get

immediate feedback about

the validity of an XML

document in Internet

Explorer 5.0

Delivery Tip

1 Open Windows Explorer

and navigate to the folder

\InetPub\WWWRoot\1905\D

emoCode\Mod08 Note that

the folder contains files

named msxmlval.htm and

msxmlval.inf

2 Right-click msxmlval.inf,

and then click Install to

install the validator utility

3 Start Internet Explorer 5.0

(or restart it if it is already

running) and open

books.xml from the same

folder

4 Right-click anywhere in

the main window of Internet

Explorer 5.0, and then click

Validate XML A message

box appears confirming that

this is a valid document

5 In Notepad, open

books.xml and edit it to

make it invalid, for example,

by deleting a <price>

element

6 Refresh the view in

Internet Explorer 5.0 and

test the validity of books.xml

again An error message

appears

XML Schemas vs DTDs

XML schemas and DTDs have a similar purpose, but XML schemas offer more precision and flexibility The following list summarizes the key differences between XML schemas and DTDs:

! Open content model XML schemas can define an “open” content model This enables additional elements and/or attributes to be present within an element without having to declare each and every element in the XML schema In contrast, DTDs define a “closed” model, which means a document cannot contain additional content except that explicitly defined in the DTD

! Data type for every element or attribute XML schemas allow you to specify a data type for an element or attribute Data types indicate the format of the data, provide for validation of the type

by the XML parser, and enable processing specific to the data type in the DOM DTDs do not support data types

! Extensible XML schemas are extensible; that is, custom schemas can be built from standard schemas For example, let’s imagine that there is a definition for an

<address> element in another schema, and that this definition meets your current needs for an <address> element With namespaces, this schema can

be used directly with a reference to the original schema, rather than copying the definition

Only one DTD document can be attached per XML document

schemas are more powerful

Microsoft recommends the

use of XML schemas for the

future

! Apply to individual elements XML schemas are applied to specific elements Generally, you might want

to apply an XML schema to the root element of the XML document in order

to define the grammar for the entire document However, you can also apply

an XML schema to isolated elements in order to define the grammar for portions of the XML document This is different from the situation with DTDs, where only a single DTD can be applied to the entire document

! Regular XML syntax XML schemas use regular XML syntax rather than the non-XML syntax used in DTDs One of the interesting consequences of this is that you can load an XML schema into the DOM and programmatically access the grammar rules within your script

For more information on XML schemas vs DTDs, refer to Module 2,

“Overview of XML Technologies.”

DTD-to-Schema conversion utility

A DTD-to-Schema conversion utility is included on the Student CD-ROM in the folder \Sampapps\DTD to Schema Conversion This utility will translate a DTD into a schema

! To run the DTD-to-Schema conversion utility

1 Open Windows® Explorer and navigate to the folder \Sampapps\DTD to Schema Conversion on the Student CD-ROM

This folder contains the dtd2schema.exe utility

2 Open a Command window and navigate to this folder

3 Run dtd2schema.exe as follows:

dtd2schema -o myxmlfile.xml mydtdfile.dtd

This creates an XML schema named myxmlfile.xml

Delivery Tip

This is an important

distinction DTD’s apply to

the entire document With

schemas, you can have

different schemas for

different elements

Delivery Tip

As an optional

demonstration, you can

describe how to use the

DTD-to-Schema conversion

utility to translate a DTD into

a schema

1 Open Windows Explorer

and navigate to the folder

haven’t discussed schema

syntax yet, so don’t go into

too much detail Just pick

out some of the

<ElementType>

statements

Causes of Invalid XML Documents

The server must ensure that the correct XML schema/DTD is applied to the document, and validate the document against this grammar

Malicious alteration of XML data

When an XML document is submitted from a client to a server, the possibility exists that the document might be tampered with in transit — document content might be maliciously added, modified, or deleted

The server must be capable of validating the XML data as it is received, rather than assuming that if the XML data was valid at the client, it is still valid when received at the server

Misinterpretation of XML schema or DTD

XML schemas and DTDs perform a dual role As well as enabling validation to take place when an XML document is loaded, they also act as a source of documentation for application developers, telling them what structure of XML

to build

XML schemas and DTDs can be quite complex to read and understand, and the developer might misinterpret the grammar rules and build an invalid XML document by mistake

Slide Objective

To describe some of the

situations that give rise to

invalid XML documents

Lead-in

There are several reasons

why invalid XML documents

get created in the first place

Consider Checkout.htm in the LitWare Books Web application Checkout.htm builds an XML document by using the shopping basket XML data island, and adds the customer ID entered by the user LitWare Books expects integer values for the customer ID, but the user can enter any type of value in the text field The developer should ensure that an integer is entered, rather than accepting anything and sending it untested to the Web server

Handling Invalid Documents

options are available:

When an invalid document is received, you can choose to abandon the document altogether and issue an error message to its creator Alternatively, you can try to recover as much meaningful data from the document as possible, and continue on that basis

Another course of action might be to ignore the validation error altogether and carry on regardless This might be appropriate if you simply wish to record the XML data that has been received, without performing much processing on the data

The following list describes techniques for handling invalid documents

! Reject the document and issue an error message This is the most straightforward way of dealing with invalid documents Return an error message to the application that generated the document, stating the reason why validation failed and the location of the problem within the XML document

This approach is suitable in situations where the creator of the invalid XML document can respond to the error message, rectify the problem, and issue a valid XML document instead

! Use the DOM to access the valid parts of the document When an XML document fails validation, it does not necessarily imply that the document is worthless It might be the case that the document contains enough valid content to meet your immediate needs

For example, imagine that a bookstore submits an XML document to a book publisher, requesting a delivery of books The XML schema might require essential information such as ISBN numbers, quantities, and the bookstore delivery address The XML schema might also require additional

information, such as the bookstore’s e-mail address for confirmation messages

Testing the validity of an

XML document is one thing

What do you do if you find

that the document is invalid?

Consider what should happen if the XML document inadvertently omits the e-mail address The publisher can still process the order by using DOM to access the essential information in the XML document The confirmation message can be sent by post rather than by e-mail

! Use XSL to transform the document into a valid format Rather than using DOM to access valid pockets of data within an invalid XML document, you can apply an XSL style sheet to transform one version

of a document into another version

For example, in the bookstore scenario described earlier, you can define a style sheet that creates an empty e-mail address element and adds it to the document

Another use of style sheets in this context is to strip out repeating elements where only a single instance is required For example, the XML document sent from the bookstore to the publisher might itemize all the authors for each book If the publisher only expects a single author per book, an XSL style sheet can be applied in order to extract the first author and ignore the others

! Ignore the validation error There are many reasons for exchanging XML documents between a client and server, such as placing orders, issuing confirmation messages, exchanging technical information, and so on In some situations, you might not need to perform detailed processing on the XML data

For example, a popular Web site might invite visitors to add their name and address to the Visitors Book In this case the Web site doesn’t perform any significant processing on the data, so it doesn’t really matter if the data format is slightly incorrect

In XML terms, the way to ignore a validation error is to create an

XMLDOM object, disable validation, and load the document into the parser

programmatically You will learn how to do this later in this module

# Writing an XML Schema

In this section, you will learn how to write a Microsoft® XML schema document and apply it to a static XML document

XML schema elements

An XML schema document may contain eight different types of elements, which define the allowed syntax and structure for a particular XML grammar You must define these elements before they can be used

Element Description

<Schema> Is the root element of the XML schema document

<ElementType> Defines an element type that may be used within the XML schema

document

<AttributeType> Defines an attribute type that may be used within the XML

schema document

<element> Appears within <ElementType>, to define the allowed child

elements for that <ElementType>

<group> Appears within <ElementType>, to define how child elements are

grouped within that <ElementType>

<attribute> Appears within <ElementType>, to define the allowed attributes

for that <ElementType>

<datatype> Appears within <ElementType> or <AttributeType>, to define the

data type for that <ElementType> or <AttributeType>

<description> Provides documentation about <Schema>, <ElementType>, or

This section describes the

detailed syntax for creating

The company Extensibility

has a product called XML

Authority that can create an

XML schemas are not yet finalized by the W3C Microsoft has defined a version of XML schemas known as XDR (XML Data Reduced) Schemas When the W3C finalizes what will be in an XML schema, Microsoft will help customers migrate from XDR schemas to XML schemas

In this module, all use of the term “XML schema” refers to the Microsoft XDR Schema definition

Note

Using a Microsoft XML Schema

Create the XML schema

An XML schema is an XML document The Microsoft definition of XML schemas requires a root element named <Schema> The <Schema> element contains all the rules defined in the XML schema document

The <Schema> element requires a name attribute that defines the name of the schema Unlike DTDs, where the name of the DTD must match the root element of the XML document, the name attribute in an XML schema may be assigned any value:

<Schema name="mySchema" >

</Schema>

The <Schema> element must be defined with the following namespace declaration It is convenient to make this the default namespace in order to avoid having to use a different namespace prefix throughout the XML schema document:

xmlns="urn:schemas-microsoft-com:xml-data"

The <Schema> element should also contain namespace declarations for any other schemas used, such as the namespace that defines the built-in data types for XML schema:

xmlns:dt="urn:schemas-microsoft-com:datatypes"

Slide Objective

To introduce the overall

format of a Microsoft XML

schema document and

show how to apply one to an

XML document

Lead-in

XML schemas are

themselves XML

documents The Microsoft

definition for XML schemas

requires a root element

named <Schema> To apply

the XML schema to an XML

document, set the

namespace of the root

element to the XML

schema

Delivery Tip

These are Microsoft

schemas and not the W3C

standard

Delivery Tip

Make sure students can

remember namespaces

from earlier in the course

Remind them about

namespaces if necessary —

the concepts and the

syntax

The following example is a minimal XML schema document:

Applying the XML schema to a static document

To apply an XML schema to a static XML document, you must add a namespace declaration of the following form to your XML document:

When the XML document is loaded into a validating XML parser, the parser loads the XML schema so that validation may take place

Notice that the XML schema is applied to the root element of the XML document, for example, <myelement>, so that it defines the grammar for the entire document It is possible to apply an XML schema to any element in an XML document, but applying it to the root element is the most common usage

The parser in Internet Explorer 5.0 does not validate XML documents by default If you wish validation to take place, you can use DOM to load the XML document programmatically, with validation enabled

Note

Defining Element Types

<ElementType

name = "element tag name"

content = "empty"|"textOnly"|"eltOnly"|"mixed" model = "open" | "closed"

order = "one" | "seq" | "many"

dt:type = "XML data type" >

</ElementType>

<ElementType

name = "element tag name"

content = "empty"|"textOnly"|"eltOnly"|"mixed" model = "open" | "closed"

order = "one" | "seq" | "many"

dt:type = "XML data type" >

<ElementType> introduces a new type of element to the XML schema, and

defines the rules for that element when it appears in the XML document

The XML schema must define a separate <ElementType> for each type of element that can appear in the XML document (unless an “open” content model

is defined) You can specify an “open” element by setting the model attribute to open

<ElementType

name = "element tag name"

content = "empty"|"textOnly"|"eltOnly"|"mixed"

model = "open" | "closed"

order = "one" | "seq" | "many"

dt:type = "XML data type" >

</ElementType>

<ElementType> has the attributes name, content, model, order, and dt:type

! name The name attribute must be provided This attribute defines the tag name for

the <ElementType>, and therefore defines a valid tag name for elements in the XML document For example, if the <ElementType> name is “book”, the XML document will have elements named <book>

! content The content attribute is optional This attribute defines the content type for

the element in the XML document

The XML schema must

define all element types

allowed in the XML

document

Delivery Tip

In the syntax, the items

shown in bold are the

default values for the

element types

Syntax

The content attribute may be assigned one of the following values

Value Description empty The element cannot contain any content whatsoever

textOnly The element can only contain text content; that is, it cannot contain

any child elements

eltOnly The element can only contain child elements; that is, it cannot contain

any free text

mixed (default) The element can contain any mixture of child elements and

free text

! model The model attribute is optional This attribute indicates whether the element

may contain extra content, in addition to that defined here The ability to define an open model is one of the key differences between XML schemas and DTDs; DTDs always use a closed model

The model attribute may be assigned one of the following values

Value Description open (default) The element may include extra elements, text content, and

attributes, in addition to that specified explicitly in the content model

closed The element may only include the elements, text content, and attributes

specified explicitly in the content model

! order The order attribute is optional This attribute defines how child elements

are ordered and combined within this element In the next section, we will see how to define child elements by using <element>

The order attribute may be assigned one of the following values

Value Description

one The element may only contain one of the possible child elements

defined for this <ElementType> The child elements are therefore mutually exclusive

seq The element must contain all the child elements defined for this

<ElementType>, in the sequence in which they are specified

many (default) The element may include some, all, or none of the child

elements, in any order

! dt:type The dt:type attribute defines the data type for the text content of this

element, such as “string”, “int”, and “float” These data types are proposed

by the W3C and are supported in the Microsoft XML parser

To use the data-type support included with Internet Explorer 5.0, your XML schema must include the “data types” namespace The top-level <Schema> element declaration should look like this:

entities Represents the XML ENTITIES type

enumeration Represents an enumerated type The enumeration values must be

supplied in the dt:values attribute (see below)

idref Represents the XML IDREF type

idrefs Represents the XML IDREFS type

nmtoken Represents the XML NMTOKEN type

nmtokens Represents the XML NMTOKENS type

notation Represents the XML NOTATION type

string Represents a string type

For more information about these primitive types, refer to Section 3.2 of the W3C XML 1.0 Recommendation at http://www.w3.org/TR/xmlschema-2 For more information on the Microsoft extensions to XML data types, refer

to the lesson “Using Data Types Within XML Documents” under the XML tutorial at http://msdn.microsoft.com/xml/TUTORIAL/default.asp, and

“XML Data Types Reference” at

The ability to define data types is another key difference between XML schemas and DTDs, and makes it easier to write code that accesses and modifies XML data programmatically

Note

Using Element Types

XML schemas define an element named <element>, which represents an

instance of an element type within another element type <element> appears within <ElementType> definitions to specify which child elements are allowed

in that element type

previously declared <ElementType> The specified element type will become a child element of the current element type

The following example defines an element type named “book”, and specifies that <book> elements will have child elements of the types <title> and <author> The <title> and <author> element types must have been declared prior to this statement

<ElementType name="book" content="eltOnly">

<element type="title" />

<element type="author" />

</ElementType>

Slide Objective

To describe how to define

child element details in an

XML schema

Lead-in

In addition to defining the

allowed element types, you

must also specify how these

element types relate to each

other Use <element> to

define parent/child

relationships between

elements

Delivery Tip

In the syntax, the items

shown in bold are the

default values for the

element types

Syntax

! minOccurs The minOccurs attribute is optional This attribute specifies the minimum

number of times a child element type may occur in the current element type

The minOccurs attribute may be assigned one of the following values Value Description

0 The specified element is not required

1 (default) The specified element must appear at least once

! maxOccurs The maxOccurs attribute is optional This attribute specifies the maximum

number of times a child element type may occur in the current element type

The maxOccurs attribute may be assigned one of the following values Value Description

1 (default) The specified element may appear only one time

* The specified element may have an unlimited number of occurrences

Example of defining child elements

Consider the following XML document:

<ElementType> definitions in the XML schema specify that <title> and

<author> are both text-only elements holding string values:

The next step is to define an <ElementType> for the <book> element type The following <ElementType> definition specifies that <book> may only contain child elements (that is, no text content) and that they must occur in the specified order The <element> definitions specify that <book> contains one <title> and one or more <author> child elements:

<ElementType name="book" content="eltOnly" order="seq">

<element type="title" />

<element type="author" maxOccurs="*" />

</ElementType>

The <element> definition for <title> implicitly states that a book must have

only one title, because the minOccurs and maxOccurs attributes have a default

value of 1 The <element> definition for <author> states that a book must have

at least one author but may have any number of authors

The final step is to define an <ElementType> for the root element in the XML document, for example, <booklist> The following <ElementType> specifies that <booklist> may contain zero or more <book> elements, but no other content is allowed:

<ElementType name="booklist" content="eltOnly">

<element type="book" minOccurs="0" maxOccurs="*" />

</ElementType>

Defining Element Groups

The <group> element appears within <ElementType> definitions and allows

child elements to be partitioned into distinct groups You can specify the sequence of elements in the group, and whether the elements are mutually exclusive

The following example shows the syntax for defining a group within an

<ElementType>, and how to define child elements within the group:

number of times the group of elements may occur in the current element type

The minOccurs attribute may be assigned one of the following values Value Description

0 The specified group is not required

1 (default) The specified group must appear at least once

Slide Objective

To describe how to group

child elements together in

an <ElementType>

Lead-in

XML schemas let you define

the order of child elements

to a great level of detail

Syntax