Wp unit III

Sub: Web Programming UNIT-3 Notes

Prepared by BHAVSINGH MALOTH [email protected]

Syllabus:

XML: Document type definition, XML Schemas, Document Object model, Presenting XML, Using XML Processors:

DOM and SAX

Introduction to XML:

What is XML?

XML stands for Extensible Markup Language

XML is a markup language much like HTML

XML was designed to carry data, not to display data

XML tags are not predefined. You must define your own tags

XML is designed to be self-descriptive

XML is a W3C Recommendation

This data might be intended to be by read by people or by machines. It can be highly

structured data such as data typically stored in databases or spreadsheets, or loosely

structured data, such as data stored in letters or manuals.

XML is self describing.

XML uses a DTD (Document Type Definition) to formally describe the data.

Difference between XML and HTML

XML and HTML were designed with different goals:

XML is not a replacement for HTML.

XML and HTML were designed with different goals:

XML was designed to describe data and to focus on what data is.

HTML was designed to display data and to focus on how data looks.

HTML is about displaying information, XML is about describing information.

XML Does Not DO Anything

Maybe it is a little hard to understand, but XML does not DO anything. XML was created

to structure, store, and transport information.

With XML You Invent Your Own Tags:

The tags in the example above (like <to> and <from>) are not defined in any XML standard. These tags are

"invented" by the author of the XML document.

XML is a complement to HTML.



It is important to understand that XML is not a replacement for HTML. In most web

applications, XML is used to transport data, while HTML is used to format and display

the data.

My best description of XML is this:

XML is a software- and hardware-independent tool for carrying information.

XML is a W3C Recommendation:

XML became a W3C Recommendation on February 10, 1998.

How can XML be used?

XML can keep data separated from your HTML

XML can be used to store data inside HTML documents

XML can be used as a format to exchange information

XML can be used to store data in files or in databases

XML Syntax

An example XML document:

<?xml version="1.0"?>

<note>

<to>Tove</to>

<from>Jani</from>

<heading>Reminder</heading>

<body>Don't forget me this weekend!</body>

</note>

Observation (explanation):

The first line in the document: The XML declaration (processing instruction) should

always be included.

It defines the XML version of the document. In this case the document conforms to the

1.0 specification of XML:


The next line defines the first element of the document (the root element):

<note>

The next lines defines 4 child elements of the root (to, from, heading, and body):



<to>Tove</to>

<from>Jani</from>



The last line defines the end of the root element:

</note>

XML Programming Rules:

All XML elements must have a closing tag

o In HTML some elements do not have to have a closing tag. The following code is

legal in HTML:

This is a paragraph

This is another paragraph

o In XML all elements must have a closing tag like this:

This is a paragraph

This is another paragraph

XML tags are case sensitive

o XML tags are case sensitive. The tag <Letter> is different from the tag <letter>.

o Opening and closing tags must therefore be written with the same case:

<Message>This is incorrect</message>

All XML elements must be properly nested

o In HTML some elements can be improperly nested within each other like this:

This text is bold and italic

o In XML all elements must be properly nested within each other like this

This text is bold and italic

<message>This is correct</message>



All XML documents must have a root tag

o All XML documents must contain a single tag pair to define the root element. All

other elements must be nested within the root element. All elements can have sub

(children) elements. Sub elements must be in pairs and correctly nested within

their parent element:

<root>

<child>

<subchild>

</subchild>

</child>

</root>

Attribute values must always be quoted

o XML elements can have attributes in name/value pairs just like in HTML. In XML

the attribute value must always be quoted. Study the two XML documents below.

The first one is incorrect, the second is correct:


<note date=12/11/99>

<to>Tove</to>

<from>Jani</from>



</note>

XML Attributes

XML attributes are normally used to describe XML elements, or to provide additional

information about elements. From HTML you can remember this construct: <IMG

SRC="computer.gif">. In this HTML example SRC is an attribute to the IMG element.

The SRC attribute provides additional information about the element.

Attributes are always contained within the start tag of an element. Here are some

examples:


<note date="12/11/99">

<to>Tove</to>

<from>Jani</from>



</note>



HTML examples:

<img src="computer.gif">

<a href="demo.asp">

XML examples:

<file type="gif">

<person id="3344">

Avoid using attributes? (I say yes!)

Why should you avoid using attributes? Should you just take my word for it? These are some of

the problems using attributes:

attributes can not contain multiple values (elements can)

attributes are not expandable (for future changes)

attributes can not describe structures (like child elements can)

attributes are more difficult to manipulate by program code

attribute values are not easy to test against a DTD

If you start using attributes as containers for XML data, you might end up with documents that

are both difficult to maintain and to manipulate. What I'm trying to say is that you should use

elements to describe your data. Use attributes only to provide information that is not relevant to

the reader.

Please don't end up like this:


<note day="12" month="11" year="99"

to="Tove" from="Jani" heading="Reminder"

body="Don't forget me this weekend!">

</note>

XML Validation

"Well Formed" XML documents

A "Well Formed" XML document is a document that conforms to the XML syntax rules.

The following is a "Well Formed" XML document:


<note>



"Valid" XML documents

A "Valid" XML document is a "Well Formed" XML document which conforms to the

rules of a Document Type Definition (DTD).

The following is the same document as above but with an added reference to a DTD:


<!DOCTYPE note SYSTEM "InternalNote.dtd">

<note>

<to>Tove</to>

<from>Jani</from>



</note>

Introduction to DTD

The purpose of a DTD is to define the legal building blocks of an XML document. It defines the document

structure with a list of legal elements. A DTD can be declared inline in your XML document, or as an

external reference.

Types of DTD files: 2 types

o Internal DTD

o External DTD

Internal DTD

This is an XML document with a Document Type Definition:


<!DOCTYPE note [

<!ELEMENT note (to,from,heading,body)>

<!ELEMENT to (#PCDATA)>

<!ELEMENT from (#PCDATA)>

<!ELEMENT heading (#PCDATA)>

<!ELEMENT body (#PCDATA)>

<to>Tove</to>

<from>Jani</from>



</note>



]>

<note>

<to>Tove</to>

<from>Jani</from>



</note>

The DTD is interpreted like this:

!ELEMENT note (in line 2) defines the element "note" as having four elements:

"to,from,heading,body".

!ELEMENT to (in line 3) defines the "to" element to be of the type "CDATA".

!ELEMENT from (in line 4) defines the "from" element to be of the type "CDATA"

and so on.....

External DTD

This is the same XML document with an external DTD:


<!DOCTYPE note SYSTEM "note.dtd">

<note>

<to>Tove</to>

<from>Jani</from>



</note>

This is a copy of the file "note.dtd" containing the Document Type Definition:







DTD - XML building blocks

The building blocks of XML documents

XML documents (and HTML documents) are made up by the following building blocks:

Elements, Tags, Attributes, Entities, PCDATA, and CDATA

This is a brief explanation of each of the building blocks:

Elements



Elements are the main building blocks of both XML and HTML documents.

Examples of HTML elements are "body" and "table". Examples of XML elements could

be "note" and "message". Elements can contain text, other elements, or be empty.

Examples of empty HTML elements are "hr", "br" and "img".

Tags

Tags are used to markup elements.

A starting tag like <element name> mark up the beginning of an element, and an ending

tag like </element name> mark up the end of an element.

Examples: A body element: <body>body text in between</body>.

A message element: <message>some message in between</message>

Declaring an Element

In the DTD, XML elements are declared with an element declaration. An element

declaration has the following syntax:

<!ELEMENT element-name (element-content)>

Empty elements

Empty elements are declared with the keyword EMPTY inside the parentheses:

<!ELEMENT element-name (EMPTY)>

example:

<!ELEMENT img (EMPTY)>

Elements with data

Elements with data are declared with the data type inside parentheses:

<!ELEMENT element-name (#CDATA)>

or

<!ELEMENT element-name

(#PCDATA)>



or

<!ELEMENT element-name (ANY)>

example:

<!ELEMENT note (#PCDATA)>

PCDATA

PCDATA means parsed character data.

Think of character data as the text found between the start tag and the end tag of an XML

element.

PCDATA is text that will be parsed by a parser. Tags inside the text will be treated as

markup and entities will be expanded.

CDATA

CDATA also means character data.

CDATA is text that will NOT be parsed by a parser. Tags inside the text will NOT be

treated as markup and entities will not be expanded.

#CDATA means the element contains character data that is not supposed to be parsed by a parser.

#PCDATA means that the element contains data that IS going to be parsed by a parser.

The keyword ANY declares an element with any content.

If a #PCDATA section contains elements, these elements must also be declared.

Elements with children (sequences)

Elements with one or more children are defined with the name of the children elements

inside the parentheses:

<!ELEMENT element-name (child-element-name)>

or

<!ELEMENT element-name (child-element-name,child-element-

name,.....)>

example:


When children are declared in a sequence separated by commas, the children must appear in the same

sequence in the document. In a full declaration, the children must also be declared, and the children can

also have children. The full declaration of the note document will be:


<!ELEMENT to (#CDATA)>



<!ELEMENT from (#CDATA)>

<!ELEMENT heading (#CDATA)>

<!ELEMENT body (#CDATA)>

Attributes

Attributes provide extra information about elements.

Attributes are placed inside the start tag of an element. Attributes come in name/value

pairs. The following "img" element has an additional information about a source file:

<img src="computer.gif" />

The name of the element is "img". The name of the attribute is "src". The value of the

attribute is "computer.gif". Since the element itself is empty it is closed by a " /".

Declaring Attributes

In the DTD, XML element attributes are declared with an ATTLIST declaration. An

attribute declaration has the following syntax:

<!ATTLIST element-name attribute-name attribute-type default-value>

As you can see from the syntax above, the ATTLIST declaration defines the element which can have the

attribute, the name of the attribute, the type of the attribute, and the default attribute value.

The attribute-type can have the following values:

Value Explanation

CDATA The value is character data

(eval|eval|..) The value must be an enumerated value

ID The value is an unique id

IDREF The value is the id of another element

IDREFS The value is a list of other ids

NMTOKEN The value is a valid XML name

NMTOKENS The value is a list of valid XML names

ENTITY The value is an entity

ENTITIES The value is a list of entities

NOTATION The value is a name of a notation



xml: The value is predefined

The attribute-default-value can have the following values:

Value Explanation

#DEFAULT value The attribute has a default value

#REQUIRED The attribute value must be included in the element

#IMPLIED The attribute does not have to be included

#FIXED value The attribute value is fixed

Attribute declaration example

DTD example:

<!ELEMENT square EMPTY>

<!ATTLIST square width CDATA "0">

XML example:

<square width="100"></square>

In the above example the element square is defined to be an empty element with the attributes width of

type CDATA. The width attribute has a default value of 0.

Default attribute value

Syntax:

<!ATTLIST element-name attribute-name CDATA "default-value">

DTD example:

<!ATTLIST payment type CDATA "check">

XML example:

<payment type="check">

Specifying a default value for an attribute, assures that the attribute will get a value even if the author of

the XML document didn't include it.

Implied attribute



Syntax:

<!ATTLIST element-name attribute-name attribute-type

#IMPLIED>

DTD example:

<!ATTLIST contact fax CDATA #IMPLIED>

XML example:

<contact fax="555-667788">

Use an implied attribute if you don't want to force the author to include an attribute and you don't have

an option for a default value either.

Required attribute

Syntax:

<!ATTLIST element-name attribute_name attribute-type #REQUIRED>

DTD example:

<!ATTLIST person number CDATA #REQUIRED>

XML example:

<person number="5677">

Use a required attribute if you don't have an option for a default value, but still want to force the attribute

to be present.

Fixed attribute value

Syntax:

<!ATTLIST element-name attribute-name attribute-type #FIXED "value">

DTD example:

<!ATTLIST sender company CDATA #FIXED "Microsoft">

XML example:

<sender company="Microsoft">

Use a fixed attribute value when you want an attribute to have a fixed value without allowing the author

to change it. If an author includes another value, the XML parser will return an error.

Enumerated attribute values

Syntax:



<!ATTLIST element-name attribute-name (eval|eval|..) default-value>

DTD example:

<!ATTLIST payment type (check|cash) "cash">

XML example:

<payment type="check">

or

<payment type="cash">

Entities

Entities as variables used to define common text. Entity references are references to

entities.

Most of you will known the HTML entity reference: " " that is used to insert an

extra space in an HTML document. Entities are expanded when a document is parsed by

an XML parser.

The following entities are predefined in XML:

Entity References Character

< <

> >

& &

" "

' '

XML Schema Basics

The Purpose of XML Schema

XML Schema is an XML-based language used to create XML-based languages and data models.

An XML schema defines element and attribute names for a class of XML documents.



XML Schema Provides the building block of XML document

XML Schema allows developer to use data types(String,Boolean,numeric,date)

XML schema language also called as Xml Schema definition language(XSDL)

The schema also specifies the structure that those documents must adhere to and the type of content that

each element can hold.

Limitations of DTD over XML Schema:

As a means of understanding the power of XML Schema, let's look at the limitations of DTD.

1. DTDs do not have built-in datatypes.

2. DTDs do not support user-derived datatypes.

3. DTDs allow only limited control over cardinality (the number of occurrences of an

element within its parent).

4. DTDs do not support Namespaces or any simple way of reusing or importing other

schemas.

XML Schema Elements Types:

The following is a high-level overview of Schema types.

1. Elements can be of simple type or complex type.



2. Simple type elements can only contain text. They can not have child elements or

attributes.

3. All the built-in types are simple types (e.g, xs:string).

4. Schema authors can derive simple types by restricting another simple type. For example,

an email type could be derived by limiting a string to a specific pattern.

5. Simple types can be atomic (e.g, strings and integers) or non-atomic (e.g, lists).

6. Complex-type elements can contain child elements and attributes as well as text.

7. By default, complex-type elements have complex content, meaning that they have child

elements.

8. Complex-type elements can be limited to having simple content, meaning they only

contain text. They are different from simple type elements in that they have attributes.

9. Complex types can be limited to having no content, meaning they are empty, but they

have may have attributes.

10. Complex types may have mixed content - a combination of text and child elements.

Why Use XML Schemas?

XML Schemas are much more powerful than DTDs.

XML Schemas Support Data Types

One of the greatest strength of XML Schemas is the support for data types.

With support for data types:

It is easier to describe allowable document content

It is easier to validate the correctness of data

It is easier to work with data from a database

It is easier to define data facets (restrictions on data)

It is easier to define data patterns (data formats)

It is easier to convert data between different data types

XML Schemas use XML Syntax

Another great strength about XML Schemas is that they are written in XML.

Some benefits of that XML Schemas are written in XML:

You don't have to learn a new language

You can use your XML editor to edit your Schema files

You can use your XML parser to parse your Schema files

You can manipulate your Schema with the XML DOM

You can transform your Schema with XSLT



XML Schemas Secure Data Communication

When sending data from a sender to a receiver, it is essential that both parts have the same "expectations" about the content.

With XML Schemas, the sender can describe the data in a way that the receiver will understand.

A date like: "03-11-2004" will, in some countries, be interpreted as 3.November and in other countries as 11.March.

However, an XML element with a data type like this:

<date type="date">2004-03-11</date>

ensures a mutual understanding of the content, because the XML data type "date" requires the format "YYYY-MM-DD".

XML Schemas are Extensible

XML Schemas are extensible, because they are written in XML.

With an extensible Schema definition you can:

Reuse your Schema in other Schemas

Create your own data types derived from the standard types

Reference multiple schemas in the same document

Well-Formed is not Enough

A well-formed XML document is a document that conforms to the XML syntax rules, like:

it must begin with the XML declaration

it must have one unique root element

start-tags must have matching end-tags

elements are case sensitive

all elements must be closed

all elements must be properly nested

all attribute values must be quoted

entities must be used for special characters

Even if documents are well-formed they can still contain errors, and those errors can have serious consequences.

Think of the following situation: you order 5 gross of laser printers, instead of 5 laser printers. With XML Schemas, most of these errors can be caught by your validating software.



XSD How To?

XML documents can have a reference to a DTD or to an XML Schema.

A Simple XML Document

Look at this simple XML document called "note.xml":


<note>

<to>Tove</to>

<from>Jani</from>



</note>

A DTD File

The following example is a DTD file called "note.dtd" that defines the elements of the XML document above ("note.xml"):

<!ELEMENT note (to, from, heading, body)>





The first line defines the note element to have four child elements: "to, from, heading, body".

Line 2-5 defines the to, from, heading, body elements to be of type "#PCDATA".

An XML Schema

The following example is an XML Schema file called "note.xsd" that defines the elements of the XML document above ("note.xml"):


<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"

targetNamespace="http://www.w3schools.com"



xmlns="http://www.w3schools.com"

elementFormDefault="qualified">

<xs:element name="note">

<xs:complexType>

<xs:sequence>

<xs:element name="to" type="xs:string"/>

<xs:element name="from" type="xs:string"/>

<xs:element name="heading" type="xs:string"/>

<xs:element name="body" type="xs:string"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:schema>

The note element is a complex type because it contains other elements. The other elements (to,

from, heading, body) are simple types because they do not contain other elements. You will learn more about simple and complex types in the following chapters.

A Reference to a DTD

This XML document has a reference to a DTD:


<!DOCTYPE note SYSTEM

"http://www.w3schools.com/dtd/note.dtd">

<note>

<to>Tove</to>

<from>Jani</from>



</note>

A Reference to an XML Schema

This XML document has a reference to an XML Schema:




<note


xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:schemaLocation="http://www.w3schools.com note.xsd">

<to>Tove</to>

<from>Jani</from>



XSD - The <schema> Element

The <schema> element is the root element of every XML Schema.

The <schema> Element

The <schema> element is the root element of every XML Schema:


<xs:schema>

...

...

</xs:schema>

The <schema> element may contain some attributes. A schema declaration often looks something like this:






...

...

</xs:schema>

The following fragment:

xmlns:xs="http://www.w3.org/2001/XMLSchema"

indicates that the elements and data types used in the schema come from the

"http://www.w3.org/2001/XMLSchema" namespace. It also specifies that the elements and data types that come from the "http://www.w3.org/2001/XMLSchema" namespace should be prefixed with xs:



This fragment:


indicates that the elements defined by this schema (note, to, from, heading, body.) come from the "http://www.w3schools.com" namespace.

This fragment:


indicates that the default namespace is "http://www.w3schools.com".

This fragment:

elementFormDefault="qualified"

indicates that any elements used by the XML instance document which were declared in this schema must be namespace qualified.

Referencing a Schema in an XML Document

This XML document has a reference to an XML Schema:


<note xmlns="http://www.w3schools.com"


xsi:schemaLocation="http://www.w3schools.com note.xsd">

<to>Tove</to>

<from>Jani</from>



</note>

The following fragment:


specifies the default namespace declaration. This declaration tells the schema-validator that all the elements used in this XML document are declared in the "http://www.w3schools.com" namespace.

Once you have the XML Schema Instance namespace available:




you can use the schemaLocation attribute. This attribute has two values, separated by a space. The

first value is the namespace to use. The second value is the location of the XML schema to use for that namespace:

xsi:schemaLocation="http://www.w3schools.com note.xsd"

XSD Simple Elements

XML Schemas define the elements of your XML files.

A simple element is an XML element that contains only text. It cannot contain

any other elements or attributes.

What is a Simple Element?

A simple element is an XML element that can contain only text. It cannot contain any other

elements or attributes.

The text can be of many different types. It can be one of the types included in the XML

Schema definition (boolean, string, date, etc.), or it can be a custom type that you can define

yourself.

Defining a Simple Element

The syntax for defining a simple element is:

<xs:element name="xxx" type="yyy"/>

where xxx is the name of the element and yyy is the data type of the element.

XML Schema has a lot of built-in data types. The most common types are:

xs:string

xs:decimal

xs:integer

xs:boolean

xs:date

xs:time

Example

Here are some XML elements:

<lastname>Refsnes</lastname>

<age>36</age>

<dateborn>1970-03-27</dateborn>



And here are the corresponding simple element definitions:

<xs:element name="lastname" type="xs:string"/>

<xs:element name="age" type="xs:integer"/>

<xs:element name="dateborn" type="xs:date"/>

Default and Fixed Values for Simple Elements

Simple elements may have a default value OR a fixed value specified.

A default value is automatically assigned to the element when no other value is specified.

In the following example the default value is "red":

<xs:element name="color" type="xs:string"

default="red"/>

A fixed value is also automatically assigned to the element, and you cannot specify another value.

In the following example the fixed value is "red":

<xs:element name="color" type="xs:string" fixed="red"/>

XSD Attributes

All attributes are declared as simple types.

What is an Attribute?

Simple elements cannot have attributes. If an element has attributes, it is considered to be of a complex type. But the attribute itself is always declared as a simple type.

How to Define an Attribute?

The syntax for defining an attribute is:

<xs:attribute name="xxx" type="yyy"/>

where xxx is the name of the attribute and yyy specifies the data type of the attribute.

XML Schema has a lot of built-in data types. The most common types are:

xs:string

xs:decimal

xs:integer



xs:boolean

xs:date

xs:time

Example

Here is an XML element with an attribute:

<lastname lang="EN">Smith</lastname>

And here is the corresponding attribute definition:

<xs:attribute name="lang" type="xs:string"/>

Default and Fixed Values for Attributes

Attributes may have a default value OR a fixed value specified.

A default value is automatically assigned to the attribute when no other value is specified.

In the following example the default value is "EN":

<xs:attribute name="lang" type="xs:string" default="EN"/>

A fixed value is also automatically assigned to the attribute, and you cannot specify another value.

In the following example the fixed value is "EN":

<xs:attribute name="lang" type="xs:string" fixed="EN"/>

Optional and Required Attributes

Attributes are optional by default. To specify that the attribute is required, use the "use" attribute:

<xs:attribute name="lang" type="xs:string" use="required"/>

Restrictions on Content



When an XML element or attribute has a data type defined, it puts restrictions on the element's or attribute's content.

If an XML element is of type "xs:date" and contains a string like "Hello World", the element will not validate.

XSD Restrictions/Facets

Restrictions are used to define acceptable values for XML elements or attributes. Restrictions on XML elements are called facets.

Restrictions on Values

The following example defines an element called "age" with a restriction. The value of age cannot be lower than 0 or greater than 120:

<xs:element name="age">

<xs:simpleType>

<xs:restriction base="xs:integer">

<xs:minInclusive value="0"/>

<xs:maxInclusive value="120"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

Restrictions on a Set of Values

To limit the content of an XML element to a set of acceptable values, we would use the enumeration constraint.

The example below defines an element called "car" with a restriction. The only acceptable values are: Audi, Golf, BMW:

<xs:element name="car">

<xs:simpleType>

<xs:restriction base="xs:string">

<xs:enumeration value="Audi"/>

<xs:enumeration value="Golf"/>

<xs:enumeration value="BMW"/>

</xs:restriction>

</xs:simpleType>

</xs:element>



Note: In this case the type "carType" can be used by other elements because it is not a part of the "car" element.

Restrictions on a Series of Values

To limit the content of an XML element to define a series of numbers or letters that can be used, we would use the pattern constraint.

The example below defines an element called "letter" with a restriction. The only acceptable value is ONE of the LOWERCASE letters from a to z:

<xs:element name="letter">

<xs:simpleType>


<xs:pattern value="[a-z]"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

Restrictions on Length

To limit the length of a value in an element, we would use the length, maxLength, and minLength constraints.

This example defines an element called "password" with a restriction. The value must be exactly eight characters:

<xs:element name="password">

<xs:simpleType>


<xs:length value="8"/>

</xs:restriction>

</xs:simpleType>

</xs:element>

This example defines another element called "password" with a restriction. The value must be minimum five characters and maximum eight characters:

<xs:element name="password">

<xs:simpleType>


<xs:minLength value="5"/>

<xs:maxLength value="8"/>

</xs:restriction>



</xs:simpleType>

</xs:element>

XSD Complex Elements

A complex element contains other elements and/or attributes.

What is a Complex Element?

A complex element is an XML element that contains other elements and/or attributes.

There are four kinds of complex elements:

empty elements

elements that contain only other elements

elements that contain only text

elements that contain both other elements and text

Note: Each of these elements may contain attributes as well!

Examples of Complex Elements

A complex XML element, "product", which is empty:

<product pid="1345"/>

A complex XML element, "employee", which contains only other elements:

<employee>

<firstname>John</firstname>

<lastname>Smith</lastname>

</employee>

A complex XML element, "food", which contains only text:

<food type="dessert">Ice cream</food>



A complex XML element, "description", which contains both elements and text:

<description>

It happened on <date lang="norwegian">03.03.99</date> ....

</description>

How to Define a Complex Element

Look at this complex XML element, "employee", which contains only other elements:

<employee>



</employee>

We can define a complex element in an XML Schema two different ways:

1. The "employee" element can be declared directly by naming the element, like this:

<xs:element name="employee">

<xs:complexType>

<xs:sequence>

<xs:element name="firstname" type="xs:string"/>


</xs:sequence>

</xs:complexType>

</xs:element>

If you use the method described above, only the "employee" element can use the specified complex type. Note that the child elements, "firstname" and "lastname", are surrounded by

the <sequence> indicator. This means that the child elements must appear in the same order as they are declared. You will learn more about indicators in the XSD Indicators chapter.

2. The "employee" element can have a type attribute that refers to the name of the complex type to use:

<xs:element name="employee" type="personinfo"/>

<xs:complexType name="personinfo">

<xs:sequence>



</xs:sequence>

</xs:complexType>



If you use the method described above, several elements can refer to the same complex type, like this:

<xs:element name="employee" type="personinfo"/>

<xs:element name="student" type="personinfo"/>

<xs:element name="member" type="personinfo"/>


<xs:sequence>



</xs:sequence>

</xs:complexType>

You can also base a complex element on an existing complex element and add some elements, like this:

<xs:element name="employee" type="fullpersoninfo"/>


<xs:sequence>



</xs:sequence>

</xs:complexType>

<xs:complexType name="fullpersoninfo">

<xs:complexContent>

<xs:extension base="personinfo">

<xs:sequence>

<xs:element name="address" type="xs:string"/>

<xs:element name="city" type="xs:string"/>

<xs:element name="country" type="xs:string"/>

</xs:sequence>

</xs:extension>

</xs:complexContent>

</xs:complexType>

XSD Empty Elements

An empty complex element cannot have contents, only attributes.

Complex Empty Elements

An empty XML element:

<product prodid="1345" />



The "product" element above has no content at all. To define a type with no content, we must

define a type that allows elements in its content, but we do not actually declare any elements, like this:

<xs:element name="product">

<xs:complexType>

<xs:complexContent>

<xs:restriction base="xs:integer">

<xs:attribute name="prodid" type="xs:positiveInteger"/>

</xs:restriction>

</xs:complexContent>

</xs:complexType>

</xs:element>

In the example above, we define a complex type with a complex content. The complexContent element signals that we intend to restrict or extend the content model of a complex type, and the restriction of integer declares one attribute but does not introduce any element content.

However, it is possible to declare the "product" element more compactly, like this:

<xs:element name="product">

<xs:complexType>


</xs:complexType>

</xs:element>

Or you can give the complexType element a name, and let the "product" element have a type

attribute that refers to the name of the complexType (if you use this method, several elements can refer to the same complex type):

<xs:element name="product" type="prodtype"/>

<xs:complexType name="prodtype">


</xs:complexType>

XSD Elements Only

An "elements-only" complex type contains an element that contains only other elements.

Complex Types Containing Elements Only

An XML element, "person", that contains only other elements:

<person>



</person>



You can define the "person" element in a schema, like this:

<xs:element name="person">

<xs:complexType>

<xs:sequence>



</xs:sequence>

</xs:complexType>

</xs:element>

Notice the <xs:sequence> tag. It means that the elements defined ("firstname" and "lastname") must appear in that order inside a "person" element.

XSD Text-Only Elements

A complex text-only element can contain text and attributes.

Complex Text-Only Elements

This type contains only simple content (text and attributes), therefore we add a simpleContent element around the content. When using simple content, you must define an extension OR a restriction within the simpleContent element, like this:

<xs:element name="somename">

<xs:complexType>

<xs:simpleContent>

<xs:restriction base="basetype">

....

....

</xs:restriction>

</xs:simpleContent>

</xs:complexType>

</xs:element>

Tip: Use the extension/restriction element to expand or to limit the base simple type for the element.

XSD Mixed Content

A mixed complex type element can contain attributes, elements, and text.

Complex Types with Mixed Content



An XML element, "letter", that contains both text and other elements:

<letter>

Dear Mr.<name>John Smith</name>.

Your order <orderid>1032</orderid>

will be shipped on <shipdate>2001-07-13</shipdate>.

</letter>

The following schema declares the "letter" element:

<xs:element name="letter">

<xs:complexType mixed="true">

<xs:sequence>

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

<xs:element name="orderid" type="xs:positiveInteger"/>

<xs:element name="shipdate" type="xs:date"/>

</xs:sequence>

</xs:complexType>

</xs:element>

Note: To enable character data to appear between the child-elements of "letter", the mixed attribute

must be set to "true". The <xs:sequence> tag means that the elements defined (name, orderid and shipdate) must appear in that order inside a "letter" element.

XSD Indicators

We can control HOW elements are to be used in documents with indicators.

Indicators

There are seven indicators:

Order indicators:

All

Choice

Sequence

Occurrence indicators:

maxOccurs

minOccurs

Group indicators:

Group name

attributeGroup name



Order Indicators

Order indicators are used to define the order of the elements.

All Indicator

The <all> indicator specifies that the child elements can appear in any order, and that each child element must occur only once:


<xs:complexType>

<xs:all>



</xs:all>

</xs:complexType>

</xs:element>

Note: When using the <all> indicator you can set the <minOccurs> indicator to 0 or 1 and the <maxOccurs> indicator can only be set to 1 (the <minOccurs> and <maxOccurs> are described later).

Choice Indicator

The <choice> indicator specifies that either one child element or another can occur:


<xs:complexType>

<xs:choice>

<xs:element name="employee" type="employee"/>

<xs:element name="member" type="member"/>

</xs:choice>

</xs:complexType>

</xs:element>

Sequence Indicator

The <sequence> indicator specifies that the child elements must appear in a specific order:


<xs:complexType>

<xs:sequence>



</xs:sequence>

</xs:complexType>

</xs:element>



Occurrence Indicators

Occurrence indicators are used to define how often an element can occur.

Note: For all "Order" and "Group" indicators (any, all, choice, sequence, group name, and group reference) the default value for maxOccurs and minOccurs is 1.

maxOccurs Indicator

The <maxOccurs> indicator specifies the maximum number of times an element can occur:


<xs:complexType>

<xs:sequence>

<xs:element name="full_name" type="xs:string"/>

<xs:element name="child_name" type="xs:string" maxOccurs="10"/>

</xs:sequence>

</xs:complexType>

</xs:element>

The example above indicates that the "child_name" element can occur a minimum of one time (the default value for minOccurs is 1) and a maximum of ten times in the "person" element.

minOccurs Indicator

The <minOccurs> indicator specifies the minimum number of times an element can occur:


<xs:complexType>

<xs:sequence>


<xs:element name="child_name" type="xs:string"

maxOccurs="10" minOccurs="0"/>

</xs:sequence>

</xs:complexType>

</xs:element>

The example above indicates that the "child_name" element can occur a minimum of zero times and a maximum of ten times in the "person" element.

Tip: To allow an element to appear an unlimited number of times, use the maxOccurs="unbounded" statement:

A working example:

An XML file called "Myfamily.xml":



<?xml version="1.0" encoding="ISO-8859-1"?>

<persons xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xsi:noNamespaceSchemaLocation="family.xsd">

<person>

<full_name>Hege Refsnes</full_name>

<child_name>Cecilie</child_name>

</person>

<person>

<full_name>Tove Refsnes</full_name>

<child_name>Hege</child_name>

<child_name>Stale</child_name>

<child_name>Jim</child_name>

<child_name>Borge</child_name>

</person>

<person>

<full_name>Stale Refsnes</full_name>

</person>

</persons>

The XML file above contains a root element named "persons". Inside this root element we have defined three "person" elements. Each "person" element must contain a "full_name" element and it can contain up to five "child_name" elements.

Here is the schema file "family.xsd":




<xs:element name="persons">

<xs:complexType>

<xs:sequence>

<xs:element name="person" maxOccurs="unbounded">

<xs:complexType>

<xs:sequence>


<xs:element name="child_name" type="xs:string"

minOccurs="0" maxOccurs="5"/>

</xs:sequence>

</xs:complexType>

</xs:element>

</xs:sequence>

</xs:complexType>

</xs:element>



</xs:schema>

Group Indicators

Group indicators are used to define related sets of elements.

Element Groups

Element groups are defined with the group declaration, like this:

<xs:group name="groupname">

...

</xs:group>

You must define an all, choice, or sequence element inside the group declaration. The following example defines a group named "persongroup", that defines a group of elements that must occur in an exact sequence:

<xs:group name="persongroup">

<xs:sequence>



<xs:element name="birthday" type="xs:date"/>

</xs:sequence>

</xs:group>

After you have defined a group, you can reference it in another definition, like this:

<xs:group name="persongroup">

<xs:sequence>



<xs:element name="birthday" type="xs:date"/>

</xs:sequence>

</xs:group>

<xs:element name="person" type="personinfo"/>


<xs:sequence>

<xs:group ref="persongroup"/>

<xs:element name="country" type="xs:string"/>

</xs:sequence>

</xs:complexType>



XML name spaces:

XML DOM:

The XML DOM defines a standard way for accessing and manipulating XML

documents.

The DOM presents an XML document as a tree-structure.

What is the DOM?

The DOM is a W3C (World Wide Web Consortium) standard.

The DOM defines a standard for accessing documents like XML and HTML:

"The W3C Document Object Model (DOM) is a platform and language-neutral interface

that allows programs and scripts to dynamically access and update the content, structure,

and style of a document."

The DOM is separated into 3 different parts / levels:

1. Core DOM - standard model for any structured document

2. XML DOM - standard model for XML documents

3. HTML DOM - standard model for HTML documents

The DOM defines the objects and properties of all document elements, and the methods

(interface) to access them.

What is the HTML DOM?

The HTML DOM defines the objects and properties of all HTML elements, and the methods


What is the XML DOM?

The XML DOM is:

A standard object model for XML

A standard programming interface for XML

Platform- and language-independent

A W3C standard



The XML DOM defines the objects and properties of all XML elements, and the methods


In other words: The XML DOM is a standard for how to get, change, add, or delete XML

elements.

XML DOM Nodes

In the DOM, everything in an XML document is a node.

DOM Nodes

According to the DOM, everything in an XML document is a node.

The DOM says:

The entire document is a document node

Every XML element is an element node

The text in the XML elements are text nodes

Every attribute is an attribute node

Comments are comment nodes

DOM Example

Look at the following XML file (books.xml):


<bookstore>

<book category="cooking">

<title lang="en">Everyday Italian</title>

<author>Giada De Laurentiis</author>

<year>2005</year>

<price>30.00</price>

</book>

<book category="children">

<title lang="en">Harry Potter</title>

<author>J K. Rowling</author>

<year>2005</year>


</book>

<book category="web">

<title lang="en">XQuery Kick Start</title>

<author>James McGovern</author>

http://www.w3schools.com/dom/books.xml



<author>Per Bothner</author>

<author>Kurt Cagle</author>

<author>James Linn</author>

<author>Vaidyanathan Nagarajan</author>

<year>2003</year>


</book>

<book category="web" cover="paperback">

<title lang="en">Learning XML</title>

<author>Erik T. Ray</author>

<year>2003</year>


</book>

</bookstore>

The root node in the XML above is named <bookstore>. All other nodes in the document are contained within <bookstore>.

The root node <bookstore> holds four <book> nodes.

The first <book> node holds four nodes: <title>, <author>, <year>, and <price>, which contains one text node each, "Everyday Italian", "Giada De Laurentiis", "2005", and "30.00".

Text is Always Stored in Text Nodes

A common error in DOM processing is to expect an element node to contain text.

However, the text of an element node is stored in a text node.

In this example: <year>2005</year>, the element node <year>, holds a text node with the value "2005".

"2005" is not the value of the <year> element!

XML DOM Node Tree

The XML DOM views an XML document as a node-tree.

All the nodes in the tree have a relationship to each other.

The XML DOM Node Tree



The XML DOM views an XML document as a tree-structure. The tree structure is called

a node-tree.

All nodes can be accessed through the tree. Their contents can be modified or deleted, and

new elements can be created.

The node tree shows the set of nodes, and the connections between them. The tree starts at

the root node and branches out to the text nodes at the lowest level of the tree:

Node Parents, Children, and Siblings

The nodes in the node tree have a hierarchical relationship to each other.

The terms parent, child, and sibling are used to describe the relationships. Parent nodes have children. Children on the same level are called siblings (brothers or sisters).

In a node tree, the top node is called the root

Every node, except the root, has exactly one parent node

A node can have any number of children

A leaf is a node with no children

Siblings are nodes with the same parent

XML DOM Parser

Most browsers have a built-in XML parser to read and manipulate XML.

The parser converts XML into a JavaScript accessible object (the XML DOM).



XML Parser

The XML DOM contains methods (functions) to traverse XML trees, access, insert, and delete

nodes.

However, before an XML document can be accessed and manipulated, it must be loaded into

an XML DOM object.

An XML parser reads XML, and converts it into an XML DOM object that can be accessed with

JavaScript.

Most browsers have a built-in XML parser.

Load an XML Document

Observation:

Code explained:

Create an XMLHTTP object

Open the XMLHTTP object

Send an XML HTTP request to the server

Set the response as an XML DOM object

XML DOM Load Functions

The code for loading XML documents can be stored in a function.



The loadXMLDoc() Function

XML DOM - Properties and Methods

Properties and methods define the programming interface to the XML DOM.

Programming Interface

The DOM models XML as a set of node objects. The nodes can be accessed with JavaScript or other programming languages. In this tutorial we use JavaScript.

The programming interface to the DOM is defined by a set standard properties and methods.

Properties are often referred to as something that is (i.e. nodename is "book").

Methods are often referred to as something that is done (i.e. delete "book").

XML DOM Properties

These are some typical DOM properties:

x.nodeName - the name of x

x.nodeValue - the value of x

x.parentNode - the parent node of x

x.childNodes - the child nodes of x

x.attributes - the attributes nodes of x

Note: In the list above, x is a node object.

XML DOM Methods

x.getElementsByTagName(name) - get all elements with a specified tag name

x.appendChild(node) - insert a child node to x

x.removeChild(node) - remove a child node from x

Note: In the list above, x is a node object.

Example

The JavaScript code to get the text from the first <title> element in books.xml:



txt=xmlDoc.getElementsByTagName("title")[0].childNodes[0].nodeValue

After the execution of the statement, txt will hold the value "Everyday Italian"

Explained:

xmlDoc - the XML DOM object created by the parser.

getElementsByTagName("title")[0] - the first <title> element

childNodes[0] - the first child of the <title> element (the text node)

nodeValue - the value of the node (the text itself)

XML DOM - Accessing Nodes

With the DOM, you can access every node in an XML document.

Accessing Nodes

You can access a node in three ways:

1. By using the getElementsByTagName() method

2. By looping through (traversing) the nodes tree.

3. By navigating the node tree, using the node relationships.

The getElementsByTagName() Method

getElementsByTagName() returns all elements with a specified tag name.

Syntax

node.getElementsByTagName("tagname");

Example

The following example returns all <title> elements under the x element:

x.getElementsByTagName("title");

Note that the example above only returns <title> elements under the x node. To return all <title> elements in the XML document use:

xmlDoc.getElementsByTagName("title");

where xmlDoc is the document itself (document node).



DOM Node List

The getElementsByTagName() method returns a node list. A node list is an array of nodes.

The following code loads "books.xml" into xmlDoc using loadXMLDoc() and stores a list of <title> nodes (a node list) in the variable x:

xmlDoc=loadXMLDoc("books.xml");

x=xmlDoc.getElementsByTagName("title");

The <title> elements in x can be accessed by index number. To access the third <title> you can write::

y=x[2];

Note: The index starts at 0.

Node Types

The documentElement property of the XML document is the root node.

The nodeName property of a node is the name of the node.

The nodeType property of a node is the type of the node.

Node Properties

In the XML DOM, each node is an object.

Objects have methods and properties, that can be accessed and manipulated by JavaScript.

Three important node properties are:

nodeName

nodeValue

nodeType

The nodeName Property

The nodeName property specifies the name of a node.

nodeName is read-only

nodeName of an element node is the same as the tag name

nodeName of an attribute node is the attribute name

nodeName of a text node is always #text

nodeName of the document node is always #document

http://w3schools.com/dom/books.xml

http://w3schools.com/dom/dom_loadxmldoc.asp



Try it yourself.

The nodeValue Property

The nodeValue property specifies the value of a node.

nodeValue for element nodes is undefined

nodeValue for text nodes is the text itself

nodeValue for attribute nodes is the attribute value

Diff between DOM and SAX:

To summarize all, lets discuss difference between both approach.

SAX Parser:

1. Event based model.

2. Serial access (flow of events).

3. Low memory usage (only events are generated).

4. To process parts of the document (catching relevant events).

5. To process the document only once.

6. Backward navigation is not possible as it sequentially processes the document.

7. Objects are to be created.

DOM Parser:

1. (Object based)Tree data structure.

2. Random access (in-memory data structure).

3. High memory usage (the document is loaded into memory).

4. To edit the document (processing the in-memory data structure).

5. To process multiple times (document loaded in memory).

6. Ease of navigation.

7. Stored as objects.

Some Questions on DOM and SAX:

1. Why do we need XML parser?

We need XML parser because we do not want to do everything in our application from scratch,

and we need some "helper" programs or libraries to do something very low-level but very

necessary to us. These low-level but necessary things include checking the well-formedness,

validating the document against its DTD or schema (just for validating parsers), resolving

character reference, understanding CDATA sections, and so on. XML parsers are just such

"helper" programs and they will do all these jobsl. With XML parsers, we are shielded from a

http://w3schools.com/dom/tryit.asp?filename=try_dom_nodename3



lot of these complexicities and we could concentrate ourselves on just programming at high-

level through the API's implemented by the parsers, and thus gain programming efficiency.

2. Is there any XML-parser debugger?

I did not see any.

3. Which one is better, SAX or DOM ?

Both SAX and DOM parser have their advantages and disadvantages. Which one is better

should depends on the characteristics of your application (please refer to some questions

below).

4. Which parser can get better speed, DOM or SAX parsers?

SAX parser can get better speed.

5. What's the difference between tree-based API and event-based API?

A tree-based API is centered around a tree structure and therefore provides interfaces on

components of a tree (which is a DOM document) such as Document interface,Node interface,

NodeList interface, Element interface, Attr interface and so on. By contrast, however, an

event-based API provides interfaces on handlers. There are four handler interfaces,

ContentHandler interface, DTDHandler interface, EntityResolver interface and

ErrorHandler interface.

6. What is the difference between a DOMParser and a SAXParser?

DOM parsers and SAX parsers work in different ways.

A DOM parser creates a tree structure in memory from the input document and then

waits for requests from client. But a SAX parser does not create any internal structure.

Instead, it takes the occurrences of components of a input document as events, and tells

the client what it reads as it reads through the input document.

A DOM parser always serves the client application with the entire document no matter

how much is actually needed by the client. But a SAX parser serves the client

application always only with pieces of the document at any given time.

With DOM parser, method calls in client application have to be explicit and forms a

kind of chain. But with SAX, some certain methods (usually overriden by the cient)

will be invoked automatically (implicitly) in a way which is called "callback" when

some certain events occur. These methods do not have to be called explicitly by the

client, though we could call them explicitly.

7. There are a lot of XML parsers available now. What makes a parser a good parser?

8. How do we decide on which parser is good?

Ideally a good parser should be fast (time efficient),space efficient, rich in functionality and

easy to use . But in reality, none of the main parsers have all these features at the same time.



For example, a DOMParser is rich in functionality (because it creates a DOM tree in memory

and allows you to access any part of the document repeatedly and allows you to modify the

DOM tree), but it is space inefficient when the document is huge, and it takes a little bit long to

learn how to work with it. A SAXParser, however, is much more space efficient in case of big

input document (because it creates no internal structure). What's more, it runs faster and is

easier to learn than DOMParser because its API is really simple. But from the functionality

point of view, it provides less functions which mean that the users themselves have to take care

of more, such as creating their own data structures. By the way, what is a good parser? I think

the answer really depends on the characteristics of your application.

1. In what cases, we prefer DOMParser to SAXParser? In what cases, we prefer

SAXParser to DOMParser?

2. What are some real world applications where using SAX parser is advantageous

than using DOM parser and vice versa?

What are the usual application for a DOM parser and for a SAX parser?

In the following cases, using SAX parser is advantageous than using DOM parser.

The input document is too big for available memory (actually in this case SAX is your

only choice)

You can process the document in small contiguous chunks of input. You do not need

the entire document before you can do useful work

You just want to use the parser to extract the information of interest, and all your

computation will be completely based on the data structures created by yourself.

Actually in most of our applications, we create data structures of our own which are

usually not as complicated as the DOM tree. From this sense, I think, the chance of

using a DOM parser is less than that of using a SAX parser.

In the following cases, using DOM parser is advantageous than using SAX parser.

Your application needs to access widely separately parts of the document at the same

time.

Your application may probably use a internal data structure which is almost as

complicated as the document itself.

Your application has to modify the document repeatedly.

Your application has to store the document for a significant amount of time through

many method calls.

Example (Use a DOM parser or a SAX parser?):

Assume that an instructor has an XML document containing all the personal information of the

students as well as the points his students made in his class, and he is now assigning final

grades for the students using an application. What he wants to produce, is a list with the SSN

and the grades. Also we assume that in his application, the instructor use no data structure such

as arrays to store the student personal information and the points.



If the instructor decides to give A's to those who earned the class average or above, and give

B's to the others, then he'd better to use a DOM parser in his application. The reason is that he

has no way to know how much is the class average before the entire document gets processed.

What he probably need to do in his application, is first to look through all the students' points

and compute the average, and then look through the document again and assign the final grade

to each student by comparing the points he earned to the class average.

If, however, the instructor adopts such a grading policy that the students who got 90 points or

more, are assigned A's and the others are assigned B's, then probably he'd better use a SAX

parser. The reason is, to assign each student a final grade, he do not need to wait for the entire

document to be processed. He could immediately assign a grade to a student once the SAX

parser reads the grade of this student.

In the above analysis, we assumed that the instructor created no data structure of his own.

What if he creates his own data structure, such as an array of strings to store the SSN and an

array of integers to sto re the points ? In this case, I think SAX is a better choice, before this

could save both memory and time as well, yet get the job done.

Well, one more consideration on this example. What if what the instructor wants to do is not to

print a list, but to save the original document back with the grade of each student updated ? In

this case, a DOM parser should be a better choice no matter what grading policy he is adopting.

He does not need to create any data structure of his own. What he needs to do is to first modify

the DOM tree (i.e., set value to the 'grade' node) and then save the whole modified tree. If he

choose to use a SAX parser instead of a DOM parser, then in this case he has to create a data

structure which is almost as complicated as a DOM tree before he could get the job done.

1. Is having two completely different ways(tree-based, event-based) to parse XML data a

problem?

No. There exist two completely diffetent ways of parsing a XML document, so that you could

choose between them according the characteristic of your application.

2. Does SAX or DOM support namespace ? If yes, how support it?

I am not sure about other parsers. But I am sure that both XerecesJ's SAXParser and

DOMParser fully support namespace. The following callback methods are provided in both of

them (note, although callback methods are typically used in SAX parser as I mentioned before,

XereceJ's DOMParser actually also provides most of these callback methods)

void startNamespaceDelScope(int prefix, int uri),which is a callback for the start of

the scope of a namespace declaration

void endNamespaceDelScope(int prefix), which is a callback for the end of the scope

of a namespace declaration

protected boolean getNamespaces(), which returns true if the parser preprocesses

namespaces

protected void setNamespaces(), which specifies whether the parser preprocesses



namespaces

What's more, XerecesJ's DOM parser also has the following methods for namespaces in the

Node interface

java.lang.String getNamespaceURI(), which gets the namespace URI of this node

java.lang.String getLocalName(), which gets the local name of this node

java.lang.String getPrefix(), which gets the namespace prefix of this node

3. For an event-based API, we are not building internal tree for the whole XML

document, then how does the document get parsed and what does the data structure in

memory look like when parsing a XML document?

The document gets parsed by the SAX parser reading the document and telling the client what

it reads. A SAX parser itself does not create or leave anything in memory, but invokes the

"callback" methods time by time depending what it sees. What data structure in memory looks

like when parsing a XML document with an event-based parser, completely depends on the

client. If the client creates no data structure, then there will be no data structure created or left

in memory both during and after the parsing.

4. Can SAX and DOM parsers be used at the same time?

Yes, of course, because the use of a DOM parser and a SAX parser is independent. For

example, if your application needs to work on two XML documents, and does different things

on each document, you could use a DOM parser on one document and a SAX parser on

another, and then combine the results or make the processings cooperate with each other.

Education

Wp unit III