Web Programming Notes by Bhavsingh Maloth

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
UNIT-3
Notes
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:
<?xml version="1.0"?>
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> <heading>Reminder</heading> <body>Don't forget me this weekend!</body>
UNIT-3
Notes
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
Sub: Web Programming All XML documents must have a root tag
UNIT-3
Notes
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:
<?xml version="1.0"?> <note date=12/11/99> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </note>
XML
<?xml version="1.0"?> <note date="12/11/99"> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </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">
UNIT-3
Notes
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:
<?xml version="1.0"?> <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:
<?xml version="1.0"?> <note> Prepared by BHAVSINGH MALOTH bhavsinghit@gmail.com

<to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </note>
UNIT-3
Notes
"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:
<?xml version="1.0"?> <!DOCTYPE note SYSTEM "InternalNote.dtd"> <note> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </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:

<?xml version="1.0"?> <!DOCTYPE note [ <!ELEMENT note (to,from,heading,body)> <!ELEMENT to (#PCDATA)> <!ELEMENT from (#PCDATA)> <!ELEMENT heading (#PCDATA)> <!ELEMENT body (#PCDATA)> Prepared by BHAVSINGH MALOTH bhavsinghit@gmail.com

]> <note> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </note>
UNIT-3
Notes
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:

<?xml version="1.0"?> <!DOCTYPE note SYSTEM "note.dtd"> <note> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </note>
This is a copy of the file "note.dtd" containing the Document Type Definition:
<?xml version="1.0"?> <!ELEMENT note (to,from,heading,body)> <!ELEMENT to (#PCDATA)> <!ELEMENT from (#PCDATA)> <!ELEMENT heading (#PCDATA)> <!ELEMENT body (#PCDATA)>
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
Prepared by BHAVSINGH MALOTH bhavsinghit@gmail.com
UNIT-3
Notes
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)> Prepared by BHAVSINGH MALOTH bhavsinghit@gmail.com

or <!ELEMENT element-name (ANY)> example: <!ELEMENT note (#PCDATA)>
UNIT-3
Notes
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-elementname,.....)> example: <!ELEMENT note (to,from,heading,body)> 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 note (to,from,heading,body)> <!ELEMENT to (#CDATA)> Prepared by BHAVSINGH MALOTH bhavsinghit@gmail.com

<!ELEMENT from (#CDATA)> <!ELEMENT heading (#CDATA)> <!ELEMENT body (#CDATA)>
UNIT-3
Notes
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 CDATA ID IDREF IDREFS NMTOKEN NMTOKENS ENTITY ENTITIES NOTATION Explanation The value is character data The value is an unique id The value is the id of another element The value is a list of other ids The value is a valid XML name The value is a list of valid XML names The value is an entity The value is a list of entities The value is a name of a notation
(eval|eval|..) The value must be an enumerated value

xml: The value is predefined
UNIT-3
Notes
The attribute-default-value can have the following values:

Value #DEFAULT value #REQUIRED #IMPLIED #FIXED value Explanation The attribute has a default value The attribute value must be included in the element The attribute does not have to be included 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
UNIT-3
Notes
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: Prepared by BHAVSINGH MALOTH bhavsinghit@gmail.com
UNIT-3
Notes
<!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. bhavsinghit@gmail.com

UNIT-3
Notes
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.
UNIT-3
Notes
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 It It It It It
is is is is is is
easier easier easier easier easier easier
to to to to to to
describe allowable document content validate the correctness of data work with data from a database define data facets (restrictions on data) define data patterns (data formats) 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 You You You You
don't have to learn a new language can use your XML editor to edit your Schema files can use your XML parser to parse your Schema files can manipulate your Schema with the XML DOM can transform your Schema with XSLT
UNIT-3
Notes
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.
UNIT-3
Notes
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":
<?xml version="1.0"?> <note> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </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 <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT
note (to, from, heading, body)> to (#PCDATA)> from (#PCDATA)> heading (#PCDATA)> body (#PCDATA)>
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"):
<?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.w3schools.com" Prepared by BHAVSINGH MALOTH bhavsinghit@gmail.com

xmlns="http://www.w3schools.com" elementFormDefault="qualified">
UNIT-3
Notes
<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:
<?xml version="1.0"?> <!DOCTYPE note SYSTEM "http://www.w3schools.com/dtd/note.dtd"> <note> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </note>
A Reference to an XML Schema

This XML document has a reference to an XML Schema:
<?xml version="1.0"?>
UNIT-3
Notes
<note xmlns="http://www.w3schools.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3schools.com note.xsd"> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body>
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:
<?xml version="1.0"?> <xs:schema> ... ... </xs:schema>

The <schema> element may contain some attributes. A schema declaration often looks something like this:
<?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.w3schools.com" xmlns="http://www.w3schools.com" elementFormDefault="qualified"> ... ... </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:
UNIT-3
Notes
targetNamespace="http://www.w3schools.com"
indicates that the elements defined by this schema (note, to, from, heading, body.) come from the "http://www.w3schools.com" namespace. This fragment:
xmlns="http://www.w3schools.com"
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:
<?xml version="1.0"?> <note xmlns="http://www.w3schools.com" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.w3schools.com note.xsd"> <to>Tove</to> <from>Jani</from> <heading>Reminder</heading> <body>Don't forget me this weekend!</body> </note>
The following fragment:
xmlns="http://www.w3schools.com"
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:
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
UNIT-3
Notes
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> Prepared by BHAVSINGH MALOTH bhavsinghit@gmail.com

And here are the corresponding simple element definitions:
UNIT-3
Notes
<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
UNIT-3
Notes
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
UNIT-3
Notes
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>
UNIT-3
Notes
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:restriction base="xs:string"> <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:restriction base="xs:string"> <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:restriction base="xs:string"> <xs:minLength value="5"/> <xs:maxLength value="8"/> </xs:restriction> Prepared by BHAVSINGH MALOTH bhavsinghit@gmail.com

</xs:simpleType> </xs:element>
UNIT-3
Notes
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>

UNIT-3
Notes
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> <firstname>John</firstname> <lastname>Smith</lastname> </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:element name="lastname" 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:element name="firstname" type="xs:string"/> <xs:element name="lastname" type="xs:string"/> </xs:sequence> </xs:complexType>
UNIT-3
Notes
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:complexType name="personinfo"> <xs:sequence> <xs:element name="firstname" type="xs:string"/> <xs:element name="lastname" type="xs:string"/> </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:complexType name="personinfo"> <xs:sequence> <xs:element name="firstname" type="xs:string"/> <xs:element name="lastname" type="xs:string"/> </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" />
UNIT-3
Notes
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:attribute name="prodid" type="xs:positiveInteger"/> </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:attribute name="prodid" type="xs:positiveInteger"/> </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> <firstname>John</firstname> <lastname>Smith</lastname> </person> Prepared by BHAVSINGH MALOTH bhavsinghit@gmail.com

You can define the "person" element in a schema, like this:
UNIT-3
Notes
<xs:element name="person"> <xs:complexType> <xs:sequence> <xs:element name="firstname" type="xs:string"/> <xs:element name="lastname" type="xs:string"/> </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

UNIT-3
Notes
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
UNIT-3
Notes
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:element name="person"> <xs:complexType> <xs:all> <xs:element name="firstname" type="xs:string"/> <xs:element name="lastname" type="xs:string"/> </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:element name="person"> <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:element name="person"> <xs:complexType> <xs:sequence> <xs:element name="firstname" type="xs:string"/> <xs:element name="lastname" type="xs:string"/> </xs:sequence> </xs:complexType> </xs:element>
UNIT-3
Notes
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:element name="person"> <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:element name="person"> <xs:complexType> <xs:sequence> <xs:element name="full_name" type="xs:string"/> <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"?>
UNIT-3
Notes
<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":
<?xml version="1.0" encoding="ISO-8859-1"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified"> <xs:element name="persons"> <xs:complexType> <xs:sequence> <xs:element name="person" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="full_name" type="xs:string"/> <xs:element name="child_name" type="xs:string" minOccurs="0" maxOccurs="5"/> </xs:sequence> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> Prepared by BHAVSINGH MALOTH bhavsinghit@gmail.com

</xs:schema>
UNIT-3
Notes
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="firstname" type="xs:string"/> <xs:element name="lastname" type="xs:string"/> <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="firstname" type="xs:string"/> <xs:element name="lastname" type="xs:string"/> <xs:element name="birthday" type="xs:date"/> </xs:sequence> </xs:group> <xs:element name="person" type="personinfo"/> <xs:complexType name="personinfo"> <xs:sequence> <xs:group ref="persongroup"/> <xs:element name="country" type="xs:string"/> </xs:sequence> </xs:complexType> Prepared by BHAVSINGH MALOTH bhavsinghit@gmail.com
Sub: Web Programming XML name spaces:
UNIT-3
Notes
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 (interface) to access them.
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
UNIT-3
Notes
The XML DOM defines the objects and properties of all XML elements, and the methods (interface) to access them. 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):
<?xml version="1.0" encoding="ISO-8859-1"?> <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> <price>29.99</price> </book> <book category="web"> <title lang="en">XQuery Kick Start</title> <author>James McGovern</author> Prepared by BHAVSINGH MALOTH bhavsinghit@gmail.com

<author>Per Bothner</author> <author>Kurt Cagle</author> <author>James Linn</author> <author>Vaidyanathan Nagarajan</author> <year>2003</year> <price>49.99</price> </book> <book category="web" cover="paperback"> <title lang="en">Learning XML</title> <author>Erik T. Ray</author> <year>2003</year> <price>39.95</price> </book> </bookstore>
UNIT-3
Notes
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

UNIT-3
Notes
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).
UNIT-3
Notes
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.
UNIT-3
Notes
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:
UNIT-3
Notes
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).
UNIT-3
Notes
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 nodeName nodeName nodeName nodeName
is read-only of an element node is the same as the tag name of an attribute node is the attribute name of a text node is always #text of the document node is always #document

Try it yourself.
UNIT-3
Notes
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. 2. 3. 4. 5. 6. 7. Event based model. Serial access (flow of events). Low memory usage (only events are generated). To process parts of the document (catching relevant events). To process the document only once. Backward navigation is not possible as it sequentially processes the document. Objects are to be created.
DOM Parser: 1. 2. 3. 4. 5. 6. 7. (Object based)Tree data structure. Random access (in-memory data structure). High memory usage (the document is loaded into memory). To edit the document (processing the in-memory data structure). To process multiple times (document loaded in memory). Ease of navigation. 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
UNIT-3
Notes
lot of these complexicities and we could concentrate ourselves on just programming at highlevel 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.
UNIT-3
Notes
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.
UNIT-3
Notes
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
UNIT-3
Notes
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.

Web Programming Notes by Bhavsingh Maloth

Cargado por

Información del documento

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Web Programming Notes by Bhavsingh Maloth

Cargado por

Copyright:

Formatos disponibles

Sub: Web Programming

Introduction to XML: What is XML?

XML is a complement to HTML.

Prepared by BHAVSINGH MALOTH

Sub: Web Programming

How can XML be used?

XML Syntax An example XML document:

Prepared by BHAVSINGH MALOTH

Sub: Web Programming

The last line defines the end of the root element:

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

XML tags are case sensitive

All XML elements must be properly nested

Prepared by BHAVSINGH MALOTH

Attribute values must always be quoted

Prepared by BHAVSINGH MALOTH

Sub: Web Programming

Avoid using attributes? (I say yes!)

XML Validation "Well Formed" XML documents

Sub: Web Programming

"Valid" XML documents

This is an XML document with a Document Type Definition:

Sub: Web Programming

This is the same XML document with an external DTD:

DTD - XML building blocks The building blocks of XML documents

Sub: Web Programming

Elements with data

Sub: Web Programming

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

Sub: Web Programming

The attribute-type can have the following values:

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

Prepared by BHAVSINGH MALOTH

Sub: Web Programming

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

Attribute declaration example

Prepared by BHAVSINGH MALOTH

Sub: Web Programming

Enumerated attribute values

Syntax: Prepared by BHAVSINGH MALOTH bhavsinghit@gmail.com

Sub: Web Programming

XML Schema Basics The Purpose of XML Schema

Prepared by BHAVSINGH MALOTH

Sub: Web Programming

Limitations of DTD over XML Schema:

XML Schema Elements Types:

Sub: Web Programming

Why Use XML Schemas?

XML Schemas Support Data Types

easier easier easier easier easier easier

XML Schemas use XML Syntax

You You You You You

Prepared by BHAVSINGH MALOTH

Sub: Web Programming

XML Schemas Secure Data Communication

XML Schemas are Extensible

Well-Formed is not Enough

Prepared by BHAVSINGH MALOTH

Sub: Web Programming

XSD How To?

A Simple XML Document

<!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT

<?xml version="1.0"?> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.w3schools.com" Prepared by BHAVSINGH MALOTH bhavsinghit@gmail.com

Sub: Web Programming