Wp unit III

Sub: Web Programming UNIT-3 Notes

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.

Prepared by BHAVSINGH MALOTH bhavsinghit@gmail.com

 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>

<message>This is correct</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

 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>

<note date="12/11/99">
<to>Tove</to>
<from>Jani</from>
XML </note> 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:

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>

<to>Tove</to>
<from>Jani</from>
</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)>

]>
<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>

<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

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



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.


Wp unit III

Recomendados

Recomendados

Mais conteúdo relacionado

Mais procurados

Mais procurados (18)

Semelhante a Wp unit III

Semelhante a Wp unit III (20)

Mais de Bhavsingh Maloth

Mais de Bhavsingh Maloth (19)

Último

Último (20)

Wp unit III