Вы находитесь на странице: 1из 527

 

XML AND WEB 
SERVICE  
VII SEM  
PTCSE (MIT) 
NOTES  
 
 
 
 
 
 
PREPARED BY  
N.VIJAYAKUMAR 
7/7 PTCSE 
MIT 
 
 
 
 
 
 

 
 
 
 
 
 
 
 
 
 
UNIT I 

XXm
mll  ––  BBeenneeffiittss   

AAddvvaannttaaggeess  O
Off  XXm
mll  O mll,,  EEddii,,  DDaattaabbaasseess  
Ovveerr  HHttm

XXm
mll  BBaasseedd  SSttaannddaarrddss  

SSttrruuccttuurriinngg  W
Wiitthh  SScchheem mll  SScchheem
maass  ––  DDttdd,,  XXm maass  
XXm
mll  PPrroocceessssiinngg  ––  DDoom
m   
XXm
mll  PPrroocceessssiinngg  ––  SSaaxx  
PPrreesseennttaattiioonn  TTeecchhnnoollooggiieess  ––  XXssll  

XXffoorrm
mss  ,,  XXhhttm
mll  
TTrraannssffoorrm
maattiioonn  ––  XXSSLLTT  

XXlliinnkk,,XXppaatthh    

XXqquueerryy    
 

 
 

 
 
 
 
 
 
 
 
 
 
 
 
 
 
 XML INTRODUCTION 
 
XML stands for eXtensible Markup Language.XML is designed to transport and store data. 

XML Document Example 
<?xml version="1.0"?> 
<note> 
    <to>Tove</to> 
    <from>Jani</from> 
    <heading>Reminder</heading> 
    <body>Don't forget me this weekend!</body> 
</note> 
Introduction to XML 
XML was designed to transport and store data.HTML was designed to display data. 

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 
 
The Difference between XML and HTML 
XML is not a replacement for HTML.XML and HTML were designed with different goals: 
• XML was designed to transport and store data, with focus on what data is. 
• HTML was designed to display data, with focus on how data looks. 
HTML is about displaying information, while XML is about carrying 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. 
<note> 

 
 
<to>Tove</to> 
<from>Jani</from> 
<heading>Reminder</heading> 
<body>Don't forget me this weekend!</body> 
</note> 
The note above is quite self descriptive. It has sender and receiver information, it also has a 
heading and a message body.But still, this XML document does not DO anything. It is just pure 
information wrapped in tags. Someone must write a piece of software to send, receive or 
display it. 
 
XML is Just Plain Text 
XML is nothing special. It is just plain text. Software that can handle plain text can also handle 
XML.  
However, XML‐aware applications can handle the XML tags specially. The functional meaning of 
the tags depends on the nature of the application.  
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. 
That is because the XML language has no predefined tags. 
The tags used in HTML (and the structure of HTML) are predefined. HTML documents can only 
use tags defined in the HTML standard (like <p>, <h1>, etc.). 
XML allows the author to define his own tags and his own document structure. 
 
XML is Not a Replacement for HTML    XML is a complement to HTML. 
It is important to understand that XML is not a replacement for HTML. In most web 
applications, XML is used to transport data, while HTML is used to format and display the data. 
My best description of XML is this: 
XML is a software‐ and hardware‐independent tool for carrying information. 
 
XML is a W3C Recommendation 
XML became a W3C Recommendation 10. February 1998. 
 
XML is Everywhere 
We have been participating in XML development since its creation. It has been amazing to see 
how quickly the XML standard has developed, and how quickly a large number of software 
vendors has adopted the standard. 
XML is now as important for the Web as HTML was to the foundation of the Web. 
XML is everywhere. It is the most common tool for data transmissions between all sorts of 
applications, and is becoming more and more popular in the area of storing and describing 
information. 

How Can XML be Used? 
XML is used in many aspects of web development, often to simplify data storage and sharing. 
 
XML Separates Data from HTML 


 
 
If you need to display dynamic data in your HTML document, it will take a lot of work to edit the 
HTML each time the data changes. 
With XML, data can be stored in separate XML files. This way you can concentrate on using 
HTML for layout and display, and be sure that changes in the underlying data will not require 
any changes to the HTML.With a few lines of JavaScript, you can read an external XML file and 
update the data content of your HTML.  
 
XML Simplifies Data Sharing 
In the real world, computer systems and databases contain data in incompatible formats.XML 
data is stored in plain text format. This provides a software‐ and hardware‐independent way of 
storing data.This makes it much easier to create data that different applications can share. 
 
XML Simplifies Data Transport 
With XML, data can easily be exchanged between incompatible systems. 
One of the most time‐consuming challenges for developers is to exchange data between 
incompatible systems over the Internet. 
Exchanging data as XML greatly reduces this complexity, since the data can be read by different 
incompatible applications. 
 
XML Simplifies Platform Changes 
Upgrading to new systems (hardware or software platforms), is always very time consuming. 
Large amounts of data must be converted and incompatible data is often lost. 
XML data is stored in text format. This makes it easier to expand or upgrade to new operating 
systems, new applications, or new browsers, without losing data. 
 
XML Makes Your Data More Available 
Since XML is independent of hardware, software and application, XML can make your data 
more available and useful. 
Different applications can access your data, not only in HTML pages, but also from XML data 
sources. 
With XML, your data can be available to all kinds of "reading machines" (Handheld computers, 
voice machines, news feeds, etc), and make it more available for blind people, or people with 
other disabilities. 
 
XML is Used to Create New Internet Languages 
A lot of new Internet languages are created with XML. Here are some examples: 
• XHTML the latest version of HTML   
• WSDL for describing available web services 
• WAP and WML as markup languages for handheld devices 
• RSS languages for news feeds 
• RDF and OWL for describing resources and ontology 
• SMIL for describing multimedia for the web   
 
If Developers Have Sense 
If they DO have sense, future applications will exchange their data in XML. 


 
 
The future might give us word processors, spreadsheet applications and databases that can 
read each other's data in a pure text format, without any conversion utilities in between. 
We can only pray that all the software vendors will agree. 

XML Tree 
XML documents form a tree structure that starts at "the root" and branches to "the leaves". 
 
An Example XML Document 
XML documents use a self‐describing and simple syntax: 
<?xml version="1.0" encoding="ISO‐8859‐1"?> 
<note> 
  <to>Tove</to> 
  <from>Jani</from> 
  <heading>Reminder</heading> 
  <body>Don't forget me this weekend!</body> 
</note> 
The first line is the XML declaration. It defines the XML version (1.0) and the encoding used 
(ISO‐8859‐1 = Latin‐1/West European character set). 
The next line describes the root element of the document (like saying: "this document is a 
note"): 
<note> 
The next 4 lines describe 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> 
And finally the last line defines the end of the root element: 
</note> 
You can assume, from this example, that the XML document contains a note to Tove from Jani. 
Don't you agree that XML is pretty self‐descriptive? 
 
XML Documents Form a Tree Structure 
XML documents must contain a root element. This element is "the parent" of all other 
elements. 
The elements in an XML document form a document tree. The tree starts at the root and 
branches to the lowest level of the tree. 
All elements can have sub elements (child elements): 
<root> 
  <child> 
    <subchild>.....</subchild> 
  </child> 
</root> 
The terms parent, child, and sibling are used to describe the relationships between elements. 
Parent elements have children. Children on the same level are called siblings (brothers or 
sisters).All elements can have text content and attributes (just like in HTML). 
 

 
 
Example: 

 
The image above represents one book in the XML below: 
<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">Learning XML</title> 
    <author>Erik T. Ray</author> 
    <year>2003</year> 
    <price>39.95</price> 
  </book> 
</bookstore> 
The root element in the example is <bookstore>. All <book> elements in the document are 
contained within <bookstore>. 
The <book> element has 4 children: <title>,< author>, <year>, <price>. 

XML Syntax Rules 
 
The syntax rules of XML are very simple and logical. The rules are easy to learn, and easy to use. 
 
All XML Elements Must Have a Closing Tag 
In HTML, you will often see elements that don't have a closing tag: 
<p>This is a paragraph 

 
 
<p>This is another paragraph 
In XML, it is illegal to omit the closing tag. All elements must have a closing tag: 
<p>This is a paragraph</p> 
<p>This is another paragraph</p> 
Note: You might have noticed from the previous example that the XML declaration did not have 
a closing tag. This is not an error. The declaration is not a part of the XML document itself, and 
it has no closing tag. 
 
XML Tags are Case Sensitive 
XML elements are defined using XML tags. 
XML tags are case sensitive. With XML, the tag <Letter> is different from the tag <letter>. 
Opening and closing tags must be written with the same case: 
<Message>This is incorrect</message>       <message>This is correct</message> 
Note: "Opening and closing tags" are often referred to as "Start and end tags". Use whatever 
you prefer. It is exactly the same thing. 
 
XML Elements Must be Properly Nested 
In HTML, you might see improperly nested elements: 
<b><i>This text is bold and italic</b></i> 
In XML, all elements must be properly nested within each other: 
<b><i>This text is bold and italic</i></b> 
In the example above, "Properly nested" simply means that since the <i> element is opened 
inside the <b> element, it must be closed inside the <b> element. 
 
XML Documents Must Have a Root Element 
XML documents must contain one element that is the parent of all other elements. This 
element is called the root element. 
<root> 
  <child> 
    <subchild>.....</subchild> 
  </child> 
</root> 
 
XML Attribute Values Must be Quoted 
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/2007> 
  <to>Tove</to> 
  <from>Jani</from> 
</note> 
<note date="12/11/2007"> 
  <to>Tove</to> 
  <from>Jani</from> 
</note> 
The error in the first document is that the date attribute in the note element is not quoted. 

 
 
 
Entity References 
Some characters have a special meaning in XML. 
If you place a character like "<" inside an XML element, it will generate an error because the 
parser interprets it as the start of a new element. This will generate an XML error: 
<message>if salary < 1000 then</message> 
To avoid this error, replace the "<" character with an entity reference: 
<message>if salary &lt; 1000 then</message> 
There are 5 predefined entity references in XML: 
&lt;  <  less than 
&gt;  >  greater than 
&amp;  &  ampersand  
&apos;  '  apostrophe 
&quot;  "  quotation mark 
Note: Only the characters "<" and "&" are strictly illegal in XML. The greater than character is 
legal, but it is a good habit to replace it. 
 
Comments in XML 
The syntax for writing comments in XML is similar to that of HTML. 
<!‐‐ This is a comment ‐‐>  
 
White‐space is Preserved in XML 
HTML truncates multiple white‐space characters to one single white‐space: 
HTML:   Hello           my name is Tove  
Output:   Hello my name is Tove. 
With XML, the white‐space in a document is not truncated. 
XML Stores New Line as LF 
In Windows applications, a new line is normally stored as a pair of characters: carriage return 
(CR) and line feed (LF). The character pair bears some resemblance to the typewriter actions of 
setting a new line. In Unix applications, a new line is normally stored as a LF character. 
Macintosh applications also use an LF to store a new line. 

XML Elements 
An XML document contains XML Elements. 
 
What is an XML Element? 
An XML element is everything from (including) the element's start tag to (including) the 
element's end tag. 
An element can contain other elements, simple text or a mixture of both. Elements can also 
have attributes. 
<bookstore> 
  <book category="CHILDREN"> 
    <title>Harry Potter</title> 
    <author>J K. Rowling</author> 
    <year>2005</year> 

 
 
    <price>29.99</price> 
  </book> 
  <book category="WEB"> 
    <title>Learning XML</title> 
    <author>Erik T. Ray</author> 
    <year>2003</year> 
    <price>39.95</price> 
  </book> 
</bookstore> 
 
In the example above, <bookstore> and <book> have element contents, because they contain 
other elements. <author> has text content because it contains text. 
In the example above only <book> has an attribute (category="CHILDREN"). 
 
XML Naming Rules 
XML elements must follow these naming rules: 
• Names can contain letters, numbers, and other characters 
• Names cannot start with a number or punctuation character 
• Names cannot start with the letters xml (or XML, or Xml, etc) 
• Names cannot contain spaces 
Any name can be used, no words are reserved. 
 
Best Naming Practices 
Make names descriptive. Names with an underscore separator are nice: <first_name>, 
<last_name>. 
Names should be short and simple, like this: <book_title> not like this: 
<the_title_of_the_book>. 
Avoid "‐" characters. If you name something "first‐name," some software may think you want 
to subtract name from first. 
Avoid "." characters. If you name something "first.name," some software may think that 
"name" is a property of the object "first." 
Avoid ":" characters. Colons are reserved to be used for something called namespaces (more 
later). 
XML documents often have a corresponding database. A good practice is to use the naming 
rules of your database for the elements in the XML documents. 
Non‐English letters like éòá are perfectly legal in XML, but watch out for problems if your 
software vendor doesn't support them. 
 
XML Elements are Extensible 
XML elements can be extended to carry more information. 
Look at the following XML example: 
<note> 
<to>Tove</to> 
<from>Jani</from> 
<body>Don't forget me this weekend!</body> 
</note> 
10 
 
 
Let's imagine that we created an application that extracted the <to>, <from>, and <body> 
elements from the XML document to produce this output: 
MESSAGE  
To: Tove 
From: Jani 
Don't forget me this weekend! 
Imagine that the author of the XML document added some extra information to it: 
<note> 
<date>2008‐01‐10</date> 
<to>Tove</to> 
<from>Jani</from> 
<heading>Reminder</heading> 
<body>Don't forget me this weekend!</body> 
</note> 
Should the application break or crash? 
No. The application should still be able to find the <to>, <from>, and <body> elements in the 
XML document and produce the same output. 
One of the beauties of XML, is that it can often be extended without breaking applications. 

XML Attributes 
XML elements can have attributes in the start tag, just like HTML. 
Attributes provide additional information about elements. 
 
XML Attributes 
From HTML you will remember this: <img src="computer.gif">. The "src" attribute provides 
additional information about the <img> element. 
In HTML (and in XML) attributes provide additional information about elements: 
<img src="computer.gif"> 
<a href="demo.asp"> 
Attributes often provide information that is not a part of the data. In the example below, the 
file type is irrelevant to the data, but important to the software that wants to manipulate the 
element: 
<file type="gif">computer.gif</file> 
XML Attributes Must be Quoted 
Attribute values must always be enclosed in quotes, but either single or double quotes can be 
used. For a person's sex, the person tag can be written like this: 
<person sex="female"> 
or like this: 
<person sex='female'> 
If the attribute value itself contains double quotes you can use single quotes, like in this 
example: 
<gangster name='George "Shotgun" Ziegler'> 
or you can use character entities: 
<gangster name="George &quot;Shotgun&quot; Ziegler"> 
 
11 
 
 
XML Elements vs. Attributes 
Take a look at these examples: 
<person sex="female"> 
  <firstname>Anna</firstname> 
  <lastname>Smith</lastname> 
</person> 
<person> 
  <sex>female</sex> 
  <firstname>Anna</firstname> 
  <lastname>Smith</lastname> 
</person> 
In the first example sex is an attribute. In the last, sex is an element. Both examples provide the 
same information. 
There are no rules about when to use attributes and when to use elements. Attributes are 
handy in HTML. In XML my advice is to avoid them. Use elements instead. 
 
My Favorite Way 
The following three XML documents contain exactly the same information: 
A date attribute is used in the first example: 
<note date="10/01/2008"> 
  <to>Tove</to> 
  <from>Jani</from> 
  <heading>Reminder</heading> 
  <body>Don't forget me this weekend!</body> 
</note> 
A date element is used in the second example: 
<note> 
  <date>10/01/2008</date> 
  <to>Tove</to> 
  <from>Jani</from> 
  <heading>Reminder</heading> 
  <body>Don't forget me this weekend!</body> 
</note> 
An expanded date element is used in the third: (THIS IS MY FAVORITE): 
<note> 
  <date> 
    <day>10</day> 
    <month>01</month> 
    <year>2008</year> 
  </date> 
  <to>Tove</to> 
  <from>Jani</from> 
  <heading>Reminder</heading> 
  <body>Don't forget me this weekend!</body> 
</note> 
 
12 
 
 
Avoid XML Attributes? 
Some of the problems with using attributes are: 
• attributes cannot contain multiple values (elements can) 
• attributes cannot contain tree structures (elements can) 
• attributes are not easily expandable (for future changes) 
Attributes are difficult to read and maintain. Use elements for data. Use attributes for 
information that is not relevant to the data.Don't end up like this: 
<note day="10" month="01" year="2008" 
to="Tove" from="Jani" heading="Reminder" 
body="Don't forget me this weekend!"> 
</note> 
 
XML Attributes for Metadata 
Sometimes ID references are assigned to elements. These IDs can be used to identify XML 
elements in much the same way as the ID attribute in HTML. This example demonstrates this: 
<messages> 
  <note id="501"> 
    <to>Tove</to> 
    <from>Jani</from> 
    <heading>Reminder</heading> 
    <body>Don't forget me this weekend!</body> 
  </note> 
  <note id="502"> 
    <to>Jani</to> 
    <from>Tove</from> 
    <heading>Re: Reminder</heading> 
    <body>I will not</body> 
  </note> 
</messages> 
The ID above is just an identifier, to identify the different notes. It is not a part of the note 
itself.What I'm trying to say here is that metadata (data about data) should be stored as 
attributes, and that data itself should be stored as elements. 

XML Validation 
XML with correct syntax is "Well Formed" XML. 
XML validated against a DTD is "Valid" XML. 
 
Well Formed XML Documents 
A "Well Formed" XML document has correct XML syntax. 
The syntax rules were described in the previous chapters: 
• XML documents must have a root element 
• XML elements must have a closing tag 
• XML tags are case sensitive 
• XML elements must be properly nested 
• XML attribute values must be quoted 
<?xml version="1.0" encoding="ISO‐8859‐1"?> 
13 
 
 
<note> 
<to>Tove</to> 
<from>Jani</from> 
<heading>Reminder</heading> 
<body>Don't forget me this weekend!</body> 
</note> 
 
Valid XML Documents 
A "Valid" XML document is a "Well Formed" XML document, which also conforms to the rules 
of a Document Type Definition (DTD): 
<?xml version="1.0" encoding="ISO‐8859‐1"?> 
<!DOCTYPE note SYSTEM "Note.dtd"> 
<note> 
<to>Tove</to> 
<from>Jani</from> 
<heading>Reminder</heading> 
<body>Don't forget me this weekend!</body> 
</note> 
The DOCTYPE declaration in the example above, is a reference to an external DTD file. The 
content of the file is shown in the paragraph below. 
 
XML DTD 
The purpose of a DTD is to define the structure of an XML document. It defines the structure 
with a list of legal elements: 
<!DOCTYPE note 

<!ELEMENT note (to,from,heading,body)> 
<!ELEMENT to (#PCDATA)> 
<!ELEMENT from (#PCDATA)> 
<!ELEMENT heading (#PCDATA)> 
<!ELEMENT body (#PCDATA)> 
]> 
 
XML Schema 
W3C supports an XML‐based alternative to DTD, called XML Schema: 
<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> 
 
14 
 
 
A General XML Validator 
To help you check the syntax of your XML files, we have created an XML validator to syntax‐
check your XML. 

Viewing XML Files 

Raw XML files can be viewed in all major browsers. 
Don't expect XML files to be displayed as HTML pages. 
 
Viewing XML Files 
<?xml version="1.0" encoding="ISO‐8859‐1"?> 
 ‐ <note> 
       <to>Tove</to>  
       <from>Jani</from>  
       <heading>Reminder</heading>  
       <body>Don't forget me this weekend!</body>  
   </note> 
Look at this XML file: note.xml 
The XML document will be displayed with color‐coded root and child elements. A plus (+) or 
minus sign (‐) to the left of the elements can be clicked to expand or collapse the element 
structure. To view the raw XML source (without the + and ‐ signs), select "View Page Source" or 
"View Source" from the browser menu. 
Note: In Chrome, Opera, and Safari, only the element text will be displayed. To view the raw 
XML, you must right click the page and select "View Source" 
 
 
Why Does XML Display Like This? 
XML documents do not carry information about how to display the data. 
Since XML tags are "invented" by the author of the XML document, browsers do not know if a 
tag like <table> describes an HTML table or a dining table. 
Without any information about how to display the data, most browsers will just display the 
XML document as it is. 
In the next chapters, we will take a look at different solutions to the display problem, using CSS, 
XSLT and JavaScript. 

Displaying XML with CSS 
With CSS (Cascading Style Sheets) you can add display information to an XML document. 
 
Displaying your XML Files with CSS? 
It is possible to use CSS to format an XML document. 
Below is an example of how to use a CSS style sheet to format an XML document: 
Below is a fraction of the XML file. The second line links the XML file to the CSS file: 
<?xml version="1.0" encoding="ISO‐8859‐1"?> 
<?xml‐stylesheet type="text/css" href="cd_catalog.css"?> 
<CATALOG> 
15 
 
 
  <CD> 
    <TITLE>Empire Burlesque</TITLE> 
    <ARTIST>Bob Dylan</ARTIST> 
    <COUNTRY>USA</COUNTRY> 
    <COMPANY>Columbia</COMPANY> 
    <PRICE>10.90</PRICE> 
    <YEAR>1985</YEAR> 
  </CD> 
  <CD> 
    <TITLE>Hide your heart</TITLE> 
    <ARTIST>Bonnie Tyler</ARTIST> 
    <COUNTRY>UK</COUNTRY> 
    <COMPANY>CBS Records</COMPANY> 
    <PRICE>9.90</PRICE> 
    <YEAR>1988</YEAR> 
  </CD> 



</CATALOG> 
Formatting XML with CSS is not the most common method. 
W3C recommend using XSLT instead. See the next chapter. 

Displaying XML with XSLT 
 
With XSLT you can transform an XML document into HTML. 
 
Displaying XML with XSLT 
XSLT is the recommended style sheet language of XML.XSLT (eXtensible Stylesheet Language 
Transformations) is far more sophisticated than CSS. 
XSLT can be used to transform XML into HTML, before it is displayed by a browser: 
Display XML with XSLT 
 
Transforming XML with XSLT on the Server 
In the example above, the XSLT transformation is done by the browser, when the browser reads 
the XML file. 
Different browsers may produce different result when transforming XML with XSLT. To reduce 
this problem the XSLT transformation can be done on the server.  

The XMLHttpRequest Object 
 
With an XMLHttpRequest you can communicate with your server from inside a web page. 
 
What is the XMLHttpRequest Object? 
The XMLHttpRequest object is the developer’s dream, because you can: 
• Update a web page with new data without reloading the page 

16 
 
 
• Request and receive new data from a server after the page has loaded  
• Communicate with a server in the background 
 
XMLHttpRequest Example 
When you type in the input box below, an HTTP request is sent to the server and name 
suggestions are returned from a name list: 
Type a letter in the input box: 
First Name 
 
Suggestions: 
 
 
Creating an XMLHttpRequest Object 
Creating an XMLHttpRequest object is done with one single line of JavaScript. 
In all modern browsers: 
var xmlhttp=new XMLHttpRequest() 
In older Microsoft browsers (IE 5 and 6): 
var xmlhttp=new ActiveXObject("Microsoft.XMLHTTP") 
In the next chapter, we will use the XMLHttpRequest object to retrieve XML information from a 
server.  
 
The XMLHttpRequest object is supported in all modern browsers 
 
Is the XMLHttpRequest Object a W3C Standard? 
The XMLHttpRequest object is not specified in any W3C recommendation. 
However, the W3C DOM Level 3 "Load and Save" specification contains some similar 
functionality, but these are not implemented in any browsers yet. 

XML 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 
The following JavaScript fragment loads an XML document ("books.xml"): 
Example 
17 
 
 
if (window.XMLHttpRequest) 
  { 
  xhttp=new XMLHttpRequest(); 
  } 
else // Internet Explorer 5/6 
  { 
  xhttp=new ActiveXObject("Microsoft.XMLHTTP"); 
  } 
xhttp.open("GET","books.xml",false); 
xhttp.send(""); 
xmlDoc=xhttp.responseXML;  
 

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 
 
Load an XML String 
The following code loads and parses an XML string: 
Example 
if (window.DOMParser) 
  { 
  parser=new DOMParser(); 
  xmlDoc=parser.parseFromString(text,"text/xml"); 
  } 
else // Internet Explorer 
  { 
  xmlDoc=new ActiveXObject("Microsoft.XMLDOM"); 
  xmlDoc.async="false"; 
  xmlDoc.loadXML(text);  
  }  
 

Note: Internet Explorer uses the loadXML() method to parse an XML string, while other 
browsers use the DOMParser object. 
 
Access Across Domains 
For security reasons, modern browsers do not allow access across domains. 
This means, that both the web page and the XML file it tries to load, must be located on the 
same server. 
The examples on W3Schools all open XML files located on the W3Schools domain. 
If you want to use the example above on one of your web pages, the XML files you load must be 
located on your own server. 
 
The XML DOM 
In the next chapter of this tutorial, you will learn how to access and retrieve data from the XML 
document object (the XML DOM). 

18 
 
 
XML DOM 
 
The DOM (Document Object Model) defines a standard way for accessing and manipulating 
documents. 
 
The XML DOM 
The XML DOM (XML Document Object Model) defines a standard way for accessing and 
manipulating XML documents.  
The DOM views XML documents as a tree‐structure. All elements can be accessed through the 
DOM tree. Their content (text and attributes) can be modified or deleted, and new elements 
can be created. The elements, their text, and their attributes are all known as nodes.  
In the examples below we use the following DOM reference to get the text from the <to> 
element: 
xmlDoc.getElementsByTagName("to")[0].childNodes[0].nodeValue 
• xmlDoc ‐ the XML document created by the parser. 
• getElementsByTagName("to")[0] ‐ the first <to> element 
• childNodes[0] ‐ the first child of the <to> element (the text node) 
• nodeValue ‐ the value of the node (the text itself) 
 
The HTML DOM 
The HTML DOM (HTML Document Object Model) defines a standard way for accessing and 
manipulating HTML documents.  
All HTML elements can be accessed through the HTML DOM. 
In the examples below we use the following DOM reference to change the text of the HTML 
element where id="to": 
document.getElementById("to").innerHTML= 
• document ‐ the HTML document 
• getElementById("to") ‐ the HTML element where id="to" 
• innerHTML ‐ the inner text of the HTML element 
 
Load an XML File ‐ A Cross browser Example 
The following code loads an XML document ("note.xml") into the XML parser: 
Example 
<html> 
<body> 
<h1>W3Schools Internal Note</h1> 
<p><b>To:</b> <span id="to"></span><br /> 
<b>From:</b> <span id="from"></span><br /> 
<b>Message:</b> <span id="message"></span> 
 
<script type="text/javascript"> 
if (window.XMLHttpRequest) 
  { 
  xhttp=new XMLHttpRequest() 
  } 

19 
 
 
else 
  { 
  xhttp=new ActiveXObject("Microsoft.XMLHTTP") 
  } 
xhttp.open("GET","note.xml",false); 
xhttp.send(""); 
xmlDoc=xhttp.responseXML; 
document.getElementById("to").innerHTML= 
xmlDoc.getElementsByTagName("to")[0].childNodes[0].nodeValue; 
document.getElementById("from").innerHTML= 
xmlDoc.getElementsByTagName("from")[0].childNodes[0].nodeValue; 
document.getElementById("message").innerHTML= 
xmlDoc.getElementsByTagName("body")[0].childNodes[0].nodeValue; 
</script> 
</body> 
</html> 
 

 
Important Note 
To extract the text "Jani" from the XML, the syntax is: 
getElementsByTagName("from")[0].childNodes[0].nodeValue 
In the XML example there is only one <from> tag, but you still have to specify the array index 
[0], because the XML parser method getElementsByTagName() returns an array of all <from> 
nodes.  
 
Load an XML String ‐ A Cross browser Example 
The following code loads and parses an XML string: 
Example 
<html> 
<body> 
<h1>W3Schools Internal Note</h1> 
<p><b>To:</b> <span id="to"></span><br /> 
<b>From:</b> <span id="from"></span><br /> 
<b>Message:</b> <span id="message"></span></p> 
<script> 
text="<note>"; 
text=text+"<to>Tove</to>"; 
text=text+"<from>Jani</from>"; 
text=text+"<heading>Reminder</heading>"; 
text=text+"<body>Don't forget me this weekend!</body>"; 
text=text+"</note>"; 
 
if (window.DOMParser) 
  { 
  parser=new DOMParser(); 
  xmlDoc=parser.parseFromString(text,"text/xml"); 
  } 
20 
 
 
else // Internet Explorer 
  { 
  xmlDoc=new ActiveXObject("Microsoft.XMLDOM"); 
  xmlDoc.async="false"; 
  xmlDoc.loadXML(text); 
  } 
document.getElementById("to").innerHTML= 
xmlDoc.getElementsByTagName("to")[0].childNodes[0].nodeValue; 
document.getElementById("from").innerHTML= 
xmlDoc.getElementsByTagName("from")[0].childNodes[0].nodeValue; 
document.getElementById("message").innerHTML= 
xmlDoc.getElementsByTagName("body")[0].childNodes[0].nodeValue; 
</script> 
</body> 
</html>  
 

Note: Internet Explorer uses the loadXML() method to parse an XML string, while other 
browsers use the DOMParser object. 

XML to HTML 

This chapter explains how to display XML data as HTML. 
 
Display XML Data in HTML 
In the example below, we loop through an XML file (cd_catalog.xml), and display each CD 
element as an HTML table row: 
Example 
<html> 
<body> 
<script type="text/javascript"> 
if (window.XMLHttpRequest) 
  { 
  xhttp=new XMLHttpRequest(); 
  } 
else // Internet Explorer 5/6 
  { 
  xhttp=new ActiveXObject("Microsoft.XMLHTTP"); 
  } 
xhttp.open("GET","cd_catalog.xml",false); 
xhttp.send(""); 
xmlDoc=xhttp.responseXML;  
document.write("<table border='1'>"); 
var x=xmlDoc.getElementsByTagName("CD"); 
for (i=0;i<x.length;i++) 
  {  
  document.write("<tr><td>"); 
  document.write(x[i].getElementsByTagName("ARTIST")[0].childNodes[0].nodeValue); 
21 
 
 
  document.write("</td><td>"); 
  document.write(x[i].getElementsByTagName("TITLE")[0].childNodes[0].nodeValue); 
  document.write("</td></tr>"); 
  } 
document.write("</table>"); 
</script> 
</body> 
</html> 
 

Example explained 
• We check the browser, and load the XML using the correct parser (explained in the 
previous chapter) 
• We create an HTML table with <table border="1"> 
• We use getElementsByTagName() to get all XML CD nodes 
• For each CD node, we display data from ARTIST and TITLE as table data. 
• We end the table with </table> 

XML Application 

This chapter demonstrates a small XML application built with HTML and JavaScript. 
 
The XML Example Document 
Look at the following XML document ("cd_catalog.xml"), that represents a CD catalog: 
<?xml version="1.0" encoding="ISO‐8859‐1"?> 
<CATALOG> 
  <CD> 
    <TITLE>Empire Burlesque</TITLE> 
    <ARTIST>Bob Dylan</ARTIST> 
    <COUNTRY>USA</COUNTRY> 
    <COMPANY>Columbia</COMPANY> 
    <PRICE>10.90</PRICE> 
    <YEAR>1985</YEAR> 
  </CD> 

Load the XML Document 
To load the XML document (cd_catalog.xml), we use the same code as we used in the XML 
Parser chapter: 
if (window.XMLHttpRequest) 
  { 
  xhttp=new XMLHttpRequest(); 
  } 
else // Internet Explorer 5/6 
  { 
  xhttp=new ActiveXObject("Microsoft.XMLHTTP"); 
  } 
xhttp.open("GET","cd_catalog.xml",false); 
xhttp.send(""); 
22 
 
 
xmlDoc=xhttp.responseXML; 
After the execution of this code, xmlDoc is an XML DOM object, accessible by JavaScript. 
 
Display XML Data as an HTML Table 
The following code displays an HTML table filled with data from the XML DOM object: 
Example 
document.write("<table border='1'>"); 
var x=xmlDoc.getElementsByTagName("CD"); 
for (i=0;i<x.length;i++) 
  { 
  document.write("<tr><td>"); 
  document.write(x[i].getElementsByTagName("ARTIST")[0].childNodes[0].nodeValue); 
  document.write("</td><td>"); 
  document.write(x[i].getElementsByTagName("TITLE")[0].childNodes[0].nodeValue); 
  document.write("</td></tr>"); 
  } 
document.write("</table>"); 
 

For each CD element in the XML document, a table row is created. Each table row contains two 
table data with ARTIST and TITLE from the current CD element. 
 
Display XML Data in any HTML Element 
XML data can be copied into any HTML element that can display text. 
The code below is part of the <head> section of the HTML file. It gets the XML data from the 
first <CD> element and displays it in the HTML element with the id="show": 
Example 
var x=xmlDoc.getElementsByTagName("CD"); 
i=0; 
function display() 

artist=(x[i].getElementsByTagName("ARTIST")[0].childNodes[0].nodeValue); 
title=(x[i].getElementsByTagName("TITLE")[0].childNodes[0].nodeValue); 
year=(x[i].getElementsByTagName("YEAR")[0].childNodes[0].nodeValue); 
txt="Artist: " + artist + "<br />Title: " + title + "<br />Year: "+ year; 
document.getElementById("show").innerHTML=txt; 

The body of the HTML document contains an onload event attribute that calls the display() 
function when the page is loaded. It also contains a <div id='show'> element to receive the XML 
data. 
<body onload="display()"> 
<div id='show'></div> 
</body>  
 

In the example above, you will only see data from the first CD element in the XML document. 
To navigate to the next CD element, you have to add some more code.  
 
Add a Navigation Script 
To add navigation to the example above, create two functions called  next() and previous(): 
23 
 
 
Example 
function next() 

if (i<x.length‐1) 
  { 
  i++; 
  display(); 
  } 

 
function previous() 

if (i>0) 
  { 
  i‐‐; 
  display(); 
  } 
}  
The next() function displays the next CD, unless you are on the last CD element. 
The previous() function displays the previous CD, unless you are at the first CD element. 
The next() and previous() functions are called by clicking next/previous buttons: 
<input type="button" onclick="previous()" value="previous" /> 
<input type="button" onclick="next()" value="next" />  
 

 
XML Namespaces 

XML Namespaces provide a method to avoid element name conflicts. 
 
Name Conflicts 
In XML, element names are defined by the developer. This often results in a conflict when 
trying to mix XML documents from different XML applications. 
This XML carries HTML table information: 
<table> 
  <tr> 
    <td>Apples</td> 
    <td>Bananas</td> 
  </tr> 
</table> 
This XML carries information about a table (a piece of furniture): 
<table> 
  <name>African Coffee Table</name> 
  <width>80</width> 
  <length>120</length> 
</table> 
If these XML fragments were added together, there would be a name conflict. Both contain a 
<table> element, but the elements have different content and meaning. 
24 
 
 
An XML parser will not know how to handle these differences. 
 
Solving the Name Conflict Using a Prefix 
Name conflicts in XML can easily be avoided using a name prefix. 
This XML carries information about an HTML table, and a piece of furniture: 
<h:table> 
  <h:tr> 
    <h:td>Apples</h:td> 
    <h:td>Bananas</h:td> 
  </h:tr> 
</h:table> 
<f:table> 
  <f:name>African Coffee Table</f:name> 
  <f:width>80</f:width> 
  <f:length>120</f:length> 
</f:table>  
In the example above, there will be no conflict because the two <table> elements have 
different names. 
 
XML Namespaces ‐ The xmlns Attribute 
When using prefixes in XML, a so‐called namespace for the prefix must be defined. 
The namespace is defined by the xmlns attribute in the start tag of an element. 
The namespace declaration has the following syntax. xmlns:prefix="URI". 
<root> 
<h:table xmlns:h="http://www.w3.org/TR/html4/"> 
  <h:tr> 
    <h:td>Apples</h:td> 
    <h:td>Bananas</h:td> 
  </h:tr> 
</h:table> 
<f:table xmlns:f="http://www.w3schools.com/furniture"> 
  <f:name>African Coffee Table</f:name> 
  <f:width>80</f:width> 
  <f:length>120</f:length> 
</f:table> 
</root>  
In the example above, the xmlns attribute in the <table> tag give the h: and f: prefixes a 
qualified namespace.When a namespace is defined for an element, all child elements with the 
same prefix are associated with the same namespace. 
Namespaces can be declared in the elements where they are used or in the XML root element: 
<root 
xmlns:h="http://www.w3.org/TR/html4/" 
xmlns:f="http://www.w3schools.com/furniture"> 
<h:table> 
  <h:tr> 
    <h:td>Apples</h:td> 
25 
 
 
    <h:td>Bananas</h:td> 
  </h:tr> 
</h:table> 
<f:table> 
  <f:name>African Coffee Table</f:name> 
  <f:width>80</f:width> 
  <f:length>120</f:length> 
</f:table> 
</root>  
Note: The namespace URI is not used by the parser to look up information. 
The purpose is to give the namespace a unique name. However, often companies use the 
namespace as a pointer to a web page containing namespace information. 
 
Uniform Resource Identifier (URI) 
A Uniform Resource Identifier (URI) is a string of characters which identifies an Internet 
Resource. 
The most common URI is the Uniform Resource Locator (URL) which identifies an Internet 
domain address. Another, not so common type of URI is the Universal Resource Name (URN). 
 
Default Namespaces 
Defining a default namespace for an element saves us from using prefixes in all the child 
elements. It has the following syntax: 
xmlns="namespaceURI" 
This XML carries HTML table information: 
<table xmlns="http://www.w3.org/TR/html4/"> 
  <tr> 
    <td>Apples</td> 
    <td>Bananas</td> 
  </tr> 
</table> 
This XML carries information about a piece of furniture: 
<table xmlns="http://www.w3schools.com/furniture"> 
  <name>African Coffee Table</name> 
  <width>80</width> 
  <length>120</length> 
</table>  
 
Namespaces in Real Use 
XSLT is an XML language that can be used to transform XML documents into other formats, like 
HTML. 
In the XSLT document below, you can see that most of the tags are HTML tags. 
The tags that are not HTML tags have the prefix xsl, identified by the namespace 
xmlns:xsl="http://www.w3.org/1999/XSL/Transform": 
<?xml version="1.0" encoding="ISO‐8859‐1"?> 
<xsl:stylesheet version="1.0" 
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> 
26 
 
 
<xsl:template match="/"> 
<html> 
<body> 
  <h2>My CD Collection</h2> 
  <table border="1"> 
    <tr> 
      <th align="left">Title</th> 
      <th align="left">Artist</th> 
    </tr> 
    <xsl:for‐each select="catalog/cd"> 
    <tr> 
      <td><xsl:value‐of select="title"/></td> 
      <td><xsl:value‐of select="artist"/></td> 
    </tr> 
    </xsl:for‐each> 
  </table> 
</body> 
</html> 
</xsl:template> 
</xsl:stylesheet>  
 
XML CDATA 

All text in an XML document will be parsed by the parser. 
But text inside a CDATA section will be ignored by the parser. 
 
PCDATA ‐ Parsed Character Data 
XML parsers normally parse all the text in an XML document. 
When an XML element is parsed, the text between the XML tags is also parsed: 
<message>This text is also parsed</message> 
The parser does this because XML elements can contain other elements, as in this example, 
where the <name> element contains two other elements (first and last): 
<name><first>Bill</first><last>Gates</last></name> 
and the parser will break it up into sub‐elements like this: 
<name> 
  <first>Bill</first> 
  <last>Gates</last> 
</name> 
Parsed Character Data (PCDATA) is a term used about text data that will be parsed by the XML 
parser.  
 
CDATA ‐ (Unparsed) Character Data 
The term CDATA is used about text data that should not be parsed by the XML parser.  
Characters like "<" and "&" are illegal in XML elements. 
"<" will generate an error because the parser interprets it as the start of a new element. 
"&" will generate an error because the parser interprets it as the start of an character entity. 
27 
 
 
Some text, like JavaScript code, contains a lot of "<" or "&" characters. To avoid errors script 
code can be defined as CDATA. 
Everything inside a CDATA section is ignored by the parser. 
A CDATA section starts with "<![CDATA[" and ends with "]]>": 
<script> 
<![CDATA[ 
function matchwo(a,b) 

if (a < b && a < 0) then 
  { 
  return 1; 
  } 
else 
  { 
  return 0; 
  } 

]]> 
</script> 
In the example above, everything inside the CDATA section is ignored by the parser. 
Notes on CDATA sections: 
A CDATA section cannot contain the string "]]>". Nested CDATA sections are not allowed. 
The "]]>" that marks the end of the CDATA section cannot contain spaces or line breaks.  

XML Encoding 

XML documents can contain non ASCII characters, like Norwegian æ ø å , or French ê è é. 
To avoid errors, specify the XML encoding, or save XML files as Unicode. 
 
XML Encoding Errors 
If you load an XML document, you can get two different errors indicating encoding problems: 
An invalid character was found in text content. 
You get this error if your XML contains non ASCII characters, and the file was saved as single‐
byte ANSI (or ASCII) with no encoding specified. 
Single byte XML file with encoding attribute. 
Same single byte XML file with no encoding attribute. 
Switch from current encoding to specified encoding not supported. 
You get this error if your XML file was saved as double‐byte Unicode (or UTF‐16) with a single‐
byte encoding (Windows‐1252, ISO‐8859‐1, UTF‐8) specified. 
You also get this error if your XML file was saved with single‐byte ANSI (or ASCII), with double‐
byte encoding (UTF‐16) specified. 
Double byte XML file without encoding. 
Same double byte XML file with single byte encoding. 
 
Windows Notepad 
Windows Notepad save files as single‐byte ANSI (ASCII) by default. 
28 
 
 
If you select "Save as...", you can specify double‐byte Unicode (UTF‐16). 
Save the XML file below as Unicode (note that the document does not contain any encoding 
attribute): 
<?xml version="1.0"?> 
<note> 
<from>Jani</from> 
<to>Tove</to> 
<message>Norwegian: æøå. French: êèé</message> 
</note> 
The file above, note_encode_none_u.xml will NOT generate an error. But if you specify a single‐
byte encoding it will. 
The following encoding (open it), will give an error message: 
<?xml version="1.0" encoding="windows‐1252"?> 
The following encoding (open it), will give an error message: 
<?xml version="1.0" encoding="ISO‐8859‐1"?> 
The following encoding (open it), will give an error message: 
<?xml version="1.0" encoding="UTF‐8"?> 
The following encoding (open it), will NOT give an error: 
<?xml version="1.0" encoding="UTF‐16"?> 
 
 
Conclusion 
• Always use the encoding attribute 
• Use an editor that supports encoding 
• Make sure you know what encoding the editor uses 
• Use the same encoding in your encoding attribute 

XML on the Server 

XML files are plain text files just like HTML files.  
XML can easily be stored and generated by a standard web server. 
 
Storing XML Files on the Server 
XML files can be stored on an Internet server exactly the same way as HTML files. 
Start Windows Notepad and write the following lines: 
<?xml version="1.0" encoding="ISO‐8859‐1"?> 
<note> 
  <from>Jani</from> 
  <to>Tove</to> 
  <message>Remember me this weekend</message> 
</note> 
Save the file on your web server with a proper name like "note.xml". 
 
Generating XML with ASP 
XML can be generated on a server without any installed XML software. 

29 
 
 
To generate an XML response from the server ‐ simply write the following code and save it as 
an ASP file on the web server: 
<% 
response.ContentType="text/xml" 
response.Write("<?xml version='1.0' encoding='ISO‐8859‐1'?>") 
response.Write("<note>") 
response.Write("<from>Jani</from>") 
response.Write("<to>Tove</to>") 
response.Write("<message>Remember me this weekend</message>") 
response.Write("</note>") 
%>  
Note that the content type of the response must be set to "text/xml". 
 
Generating XML with PHP 
To generate an XML response from the server using PHP, use following code: 
<?php 
header("Content‐type: text/xml"); 
echo "<?xml version='1.0' encoding='ISO‐8859‐1'?>"; 
echo "<note>"; 
echo "<from>Jani</from>"; 
echo "<to>Tove</to>"; 
echo "<message>Remember me this weekend</message>"; 
echo "</note>"; 
?>  
Note that the content type of the response header must be set to "text/xml". 
 
Generating XML From a Database 
XML can be generated from a database without any installed XML software. 
To generate an XML database response from the server, simply write the following code and 
save it as an ASP file on the web server: 
<% 
response.ContentType = "text/xml" 
set conn=Server.CreateObject("ADODB.Connection") 
conn.provider="Microsoft.Jet.OLEDB.4.0;" 
conn.open server.mappath("/db/database.mdb") 
sql="select fname,lname from tblGuestBook" 
set rs=Conn.Execute(sql) 
response.write("<?xml version='1.0' encoding='ISO‐8859‐1'?>") 
response.write("<guestbook>") 
while (not rs.EOF) 
response.write("<guest>") 
response.write("<fname>" & rs("fname") & "</fname>") 
response.write("<lname>" & rs("lname") & "</lname>") 
response.write("</guest>") 
rs.MoveNext() 
wend 
30 
 
 
rs.close() 
conn.close() 
response.write("</guestbook>") 
%> 
 
Transforming XML with XSLT on the Server 
This ASP transforms an XML file to XHTML on the server: 
<% 
'Load XML 
set xml = Server.CreateObject("Microsoft.XMLDOM") 
xml.async = false 
xml.load(Server.MapPath("simple.xml")) 
'Load XSL 
set xsl = Server.CreateObject("Microsoft.XMLDOM") 
xsl.async = false 
xsl.load(Server.MapPath("simple.xsl")) 
'Transform file 
Response.Write(xml.transformNode(xsl)) 
%>  
Example explained 
• The first block of code creates an instance of the Microsoft XML parser (XMLDOM), and 
loads the XML file into memory. 
• The second block of code creates another instance of the parser and loads the XSL file 
into memory. 
• The last line of code transforms the XML document using the XSL document, and sends 
the result as XHTML to your browser. Nice! 
 
Saving XML To a File Using ASP 
This ASP example creates a simple XML document and saves it on the server: 
<% 
text="<note>" 
text=text & "<to>Tove</to>" 
text=text & "<from>Jani</from>" 
text=text & "<heading>Reminder</heading>" 
text=text & "<body>Don't forget me this weekend!</body>" 
text=text & "</note>" 
set xmlDoc=Server.CreateObject("Microsoft.XMLDOM") 
xmlDoc.async="false" 
xmlDoc.loadXML(text) 
xmlDoc.Save("test.xml") 
%>  
XML DOM Advanced 
 
The XML DOM (Document Object Model) defines a standard way for accessing and 
manipulating XML documents. 

31 
 
 
 
The XML DOM 
The DOM views XML documents as a tree‐structure. All elements can be accessed through the 
DOM tree. Their content (text and attributes) can be modified or deleted, and new elements 
can be created. The elements, their text, and their attributes are all known as nodes.  
In an earlier chapter of this tutorial we introduced the XML DOM , and used the XML DOM 
getElementsByTagName() method to retrieve data from a DOM tree. 
In this chapter we will describe some other commonly used XML DOM methods. In the 
examples below, we have used the XML file: books.xml.  
 
Get the Value of an Element 
The following code retrieves the text value of the first <title> element: 
Example 
x=xmlDoc.getElementsByTagName("title")[0].childNodes[0]; 
txt=x.nodeValue;  
 

 
Get the Value of an Attribute 
The following code retrieves the text value of the "lang" attribute of the first <title> element: 
Example 
txt=xmlDoc.getElementsByTagName("title")[0].getAttribute("lang");  
 

 
Change the Value of an Element 
The following code changes the text value of the first <title> element: 
Example 
x=xmlDoc.getElementsByTagName("title")[0].childNodes[0]; 
x.nodeValue="Easy Cooking";  
 

 
Change the Value of an Attribute 
The setAttribute() method can be used to change the value of an existing attribute, or to create 
a new attribute. 
The following code adds a new attribute called "edition" (with the value "first") to each <book> 
element: 
Example 
x=xmlDoc.getElementsByTagName("book"); 
 
for(i=0;i<x.length;i++) 
  { 
  x[i].setAttribute("edition","first"); 
  }  
 

 
Create an Element 
The createElement() method creates a new element node. 
The createTextNode() method creates a new text node. 
The appendChild() method adds a child node to a node (after the last child). 
To create a new element with text content, it is necessary to create both an element node and 
a text node. 
32 
 
 
The following code creates an element (<edition>), and adds it to the first <book> element: 
Example 
newel=xmlDoc.createElement("edition"); 
newtext=xmlDoc.createTextNode("First"); 
newel.appendChild(newtext); 
 
x=xmlDoc.getElementsByTagName("book"); 
x[0].appendChild(newel);  
 

Example explained: 
• Create an <edition> element 
• Create a text node with value = "First" 
• Append the text node to the <edition> element 
• Append the <edition> element to the first <book> element 
 
Remove an Element 
The removeChild() method removes a specified node (or element). 
The following code fragment will remove the first node in the first <book> element: 
Example 
x=xmlDoc.getElementsByTagName("book")[0]; 
 
x.removeChild(x.childNodes[0]);  
 

Note: The result of the example above may be different depending on what browser you use. 
Firefox treats new lines as empty text nodes, Internet Explorer does not. You can read more 
about this and how to avoid it in the XML DOM tutorial. 
 
XML in Real Life 

Some examples of how XML can be used to exchange information. 
 
Example: XML News 
XMLNews is a specification for exchanging news and other information. 
Using such a standard makes it easier for both news producers and news consumers to 
produce, receive, and archive any kind of news information across different hardware, 
software, and programming languages. 
An example XMLNews document: 
<?xml version="1.0" encoding="ISO‐8859‐1"?> 
<nitf> 
  <head> 
    <title>Colombia Earthquake</title> 
  </head> 
  <body> 
    <headline> 
      <hl1>143 Dead in Colombia Earthquake</hl1> 
    </headline> 
    <byline> 
      <bytag>By Jared Kotler, Associated Press Writer</bytag> 
33 
 
 
/    </byline> 
    <dateline> 
      <location>Bogota, Colombia</location> 
      <date>Monday January 25 1999 7:28 ET</date> 
    </dateline> 
  </body> 
</nitf> 
Example: XML Weather Service 
An example of an XML national weather service from NOAA (National Oceanic and Atmospheric 
Administration): 
<?xml version="1.0" encoding="ISO‐8859‐1" ?> 
<current_observation> 
<credit>NOAA's National Weather Service</credit> 
<credit_URL>http://weather.gov/</credit_URL> 
<image> 
  <url>http://weather.gov/images/xml_logo.gif</url> 
  <title>NOAA's National Weather Service</title> 
  <link>http://weather.gov</link> 
</image> 
<location>New York/John F. Kennedy Intl Airport, NY</location> 
<station_id>KJFK</station_id> 
<latitude>40.66</latitude> 
<longitude>‐73.78</longitude> 
<observation_time_rfc822>Mon, 11 Feb 2008 06:51:00 ‐0500 EST 
</observation_time_rfc822> 
<weather>A Few Clouds</weather> 
<temp_f>11</temp_f> 
<temp_c>‐12</temp_c> 
<relative_humidity>36</relative_humidity> 
<wind_dir>West</wind_dir> 
<wind_degrees>280</wind_degrees> 
<wind_mph>18.4</wind_mph> 
<wind_gust_mph>29</wind_gust_mph> 
<pressure_mb>1023.6</pressure_mb> 
<pressure_in>30.23</pressure_in> 
<dewpoint_f>‐11</dewpoint_f> 
<dewpoint_c>‐24</dewpoint_c> 
<windchill_f>‐7</windchill_f> 
<windchill_c>‐22</windchill_c> 
<visibility_mi>10.00</visibility_mi> 
<icon_url_base>http://weather.gov/weather/images/fcicons/</icon_url_base> 
<icon_url_name>nfew.jpg</icon_url_name> 
<disclaimer_url>http://weather.gov/disclaimer.html</disclaimer_url> 
<copyright_url>http://weather.gov/disclaimer.html</copyright_url> 
</current_observation> 

34 
 
 
XML Summary. What is Next? 
 
XML Summary 

XML can be used to exchange, share, and store data. 
XML documents form a tree structure that starts at "the root" and branches to "the leaves". 
XML has very simple syntax rules. XML with correct syntax is "Well Formed". Valid XML also 
validates against a DTD. 
XSLT is used to transform XML into other formats like HTML. 
All modern browsers have a built‐in XML parser that can read and manipulate XML. 
The DOM (Document Object Model) defines a standard way for accessing XML. 
The XMLHttpRequest object provides a way to communicate with a server after a web page has 
loaded. 
XML Namespaces provide a method to avoid element name conflicts. 
Text inside a CDATA section is ignored by the parser. 
Our XML examples also represent a summary of this XML tutorial. 

 
What to Study Next? 

Our recommendation is to learn about the XML DOM and XSLT. 
If you want to learn more about validating XML, we recommend DTD and XML Schema. 
Below is a short description of each subject. 

 
XML DOM (Document Object Model) 

The XML DOM defines a standard way for accessing and manipulating XML documents. 
The XML DOM is platform and language independent and can be used by any programming 
language like Java, JavaScript, and VBScript. 
If you want to learn more about the DOM, please visit our XML DOM tutorial. 

 
XSLT (XML Stylesheet Language Transformations) 

XSLT is the style sheet language for XML files. 
With XSLT you can transform XML documents into other formats, like XHTML. 
If you want to learn more about XSLT, please visit our XSLT tutorial. 

35 
 
 
XML DTD (Document Type Definition) 

The purpose of a DTD is to define what elements, attributes and entities is legal in an XML 
document. 
With DTD, each of your XML files can carry a description of its own format with it. 
DTD can be used to verify that the data you receive, and your own data, is valid. 
If you want to learn more about DTD, please visit our DTD tutorial. 

 
XML Schema 

XML Schema is an XML based alternative to DTD. 
Unlike DTD, XML Schemas has support for datatypes, and XML Schema use XML Syntax. 

XML‐ The Benefits 
 
• Simplicity 
Information coded in XML is easy to read and understand, plus it can be processed easily 
by computers. 
• Openness  
XML is a W3C standard, endorsed by software industry market leaders. 
• Extensibility  
There is no fixed set of tags. New tags can be created as they are needed.  
• Self‐description  
In traditional databases, data records require schemas set up by the database 
administrator. XML documents can be stored without such definitions, because they 
contain meta data in the form of tags and attributes.XML Provides a basis for author 
identification and versioning at the element level. Any XML tag can possess an unlimited 
number of attributes such as author or version. 
• Contains machine‐readable context information  
Tags, attributes and element structure provide context information that can be used to 
interpret the meaning of content, opening up new possibilities for highly efficient search 
engines, intelligent data mining, agents, etc. 
This is a major advantage over HTML or plain text, where context information is difficult 
or impossible to evaluate. 
• Separates content  from presentation  
XML tags describe meaning not presentation. The motto of HTML is: "I know how it 
looks", whereas the motto of XML is: "I know what it means, and you tell me how it 
should look." The look and feel of an XML document can be controlled by XSL style 
sheets, allowing the look of a document (or of a complete Web site) to be changed 
without touching the content of the document. Multiple views or presentations of the 
same content are easily rendered. 
• Supports multilingual documents and Unicode  
This is important for the internationalization of applications. 

36 
 
 
• Facilitates the comparison and aggregation of data  
The tree structure of XML documents allows documents to be compared and 
aggregated efficiently element by element. 
• Can embed multiple data types  
XML documents can contain any possible data type ‐ from multimedia data (image, 
sound, video) to active components (Java applets, ActiveX). 
• Can embed existing data  
Mapping existing data structures like file systems or relational databases to XML is 
simple. XML supports multiple data formats and can cover all existing data structures 
and . 
• Provides a 'one‐server view' for distributed data  
XML documents can consist of nested elements that are distributed over multiple 
remote servers. XML is currently the most sophisticated format for distributed data ‐ the 
World Wide Web can be seen as one huge XML database. 
• Rapid adoption by  industry  
Software AG, IBM, Sun, Microsoft, Netscape, DataChannel, SAP and many others have 
already announced support for XML. Microsoft will use XML as the exchange format for 
its Office product line, while both Microsoft's and Netscape's Web browsers support 
XML. SAP has announced support of XML through the SAP Business Connector with R/3. 
Software AG supports XML in its Bolero and Natural product lines and provides Tamino, 
a native XML database. 
 

Introduction 
XML is structured 
XML documents are easily committed to a persistence layer 
XML is platform independent, textual information 
XML is an open standard 
XML is language independent 
DOM and SAX are open, language‐independent set of interfaces 
XML is web enabled 
XML is totally extensible 
XML supports shareable structure (using DTDs) 
XML enables interoperability 
Vision 

Introduction  
 

There  is  a  lot  of  hype  surrounding  XML,  and  a  lot  of  hype  surrounding  Java.  Together  these 
technologies propose to solve many of the most common (and persistent) general computing 
problems that have been around for the last 20 years. XML and Java are not revolutionary in 
the approach to solving these problems of interoperability of code and data across and within 
platform and application boundaries. Rather, XML and Java provide solutions to these problems 
by using the most successful strategies and techniques that have been honed and refined over 
the last 20 years of computing. 
37 
 
 
In the following paragraphs, I will highlight some of the most basic and important advantages 
that XML and Java provide to almost any system that uses them properly. This is by no means a 
comprehensive list of benefits, but items in this list should appear across just about any use of 
XML and Java technologies. 
I will take a break from my normal pragmatic approach to getting you (the programmer) started 
with  using  XML  and  Java  and  just  talk  about  the  high  level  (design  level)  benefits  of  this 
wonderful combination. A good design is important to a good implementation for any system. 

XML is structured  
 

When you create your data using an XML editor (that you can write), you can not only input the 
content of your data, but also define the structural relationships that exist inside your data. By 
allowing you to define your own tags and create the proper structural relationships in your 
information (with a DTD), you can use any XML parser to check the validity and integrity of the 
data stored in your XML documents. This makes it very easy to validate the structure and 
content of your information when you use XML. Without XML, you could also provide this 
validation feature at the expense of developing the code to this yourself. XML is a great time 
saver because most of the features that are available in XML are used by most programmers 
when working on most projects.  
By using XML and Java, you can quickly create and use information that is properly structured 
and valid. By using (or creating) DTDs and storing your information in XML documents, you have 
a cross‐platform and language independent data validation mechanism (for free) in all your 
projects! 
You might use XML to define file formats to store information that is generated and used by 
your applications. This is another use of the structured nature of XML. The only limitation is 
that binary information can’t be embedded in the body of XML documents. For example, if you 
wrote a word processor in Java, you might choose to save your word processor documents to 
an XML (actually your ApplicationML) file. If you use a DTD then your word processor would 
also get input file format validation as a feature for free. There are many other advantages to 
using XML and a file storage format for your applications which will be illustrated later in the 
chapter. 
Here are some benefits of the structured nature of XML: 

• XML parsers make your application code more reliable and quick to develop by 
providing validity checking on your XML documents (if you use a DTD).  
• XML allows you to easily generate XML documents (that contain your information), 
since it is so structured.  
• XML parsers allow you to code faster by giving you a parser for your all your XML 
documents (with and without DTDs).  

XML documents are easily committed to a persistence layer  
 

XML documents may be stored in files or databases. When stored in files, XML documents are 
simply plain text files with tags (and possibly DTDs). It is very easy to save your XML documents 
38 
 
 
to a text file and pass the text file around to other machines, platforms and programs (as long 
as they can understand the data). In the worst case scenario, XML documents (files) can be 
viewed in a text editor on just about any platform.  
XML documents are also naturally committed to a database (relational or object) or any other 
kind of XML document store. There are commercial products available which allow you to save 
XML documents to an XML storage layer (which is not a database per se), like Datachannel’s 
XStore and ODI’s eXcelon. These XML store solutions are quite expensive ($10,000 to $20,000 
range). 
XML documents are also quite naturally retrieved from a persistence layer (databases, file 
systems, XML stores). This lends XML to be used in real world applications where the 
information being used by different parts of a system is the most important thing. 

XML is platform independent, textual information  
 

Information in an XML document is stored in plain‐text. This might seem like a restriction if 
were thinking of embedding binary information in an XML document. There are several 
advantages to keeping things plain text. First, it is easy to write parsers and all other XML 
enabling technology on different platforms. Second, it makes everything very interoperable by 
staying with the lowest common denominator approach. This is the whole reason the web is so 
successful despite all its flaws. By accepting and sending information in plain text format, 
programs running on disparate platforms can communicate with each other. This also makes it 
easy to integrate new programs on top of older ones (without rewriting the old programs), by 
simply making the interface between the new and old program use XML. 
For example, if you have an address book document stored in an XML file, created on a Mac, 
that you would like to share with someone who has a PC, you can simply email them the plain 
text address book XML document. This cant be done with binary encoded information which is 
totally platform (and program) dependent. 
Another example is web enabling legacy systems. It is very feasible to create a Java web 
ennoblement application server that simply uses the services provided by the underlying legacy 
system. Instead of rewriting the legacy system, if the system can be made to communicate 
results and parameters through XML, the new and old system can work together without 
throwing away a company’s investment in the legacy system. 

XML is an open standard  
 

By making the W3C the keeper of the XML standard, it ensures that no one vendor should be 
able to cause interoperability problems to occur between systems that use the open standard. 
This should be reassuring to most companies making an investment in this technology, by being 
vendor neutral, this solution proposes to keep even small companies out of reach of big 
companies choosing to change the standards on them. For example, if a big company chooses 
to change the platform at its whim, then most other companies relying on that platform suffer. 
By keeping all data in XML and using XML in communications protocols, companies can 
maximize the lifetime of their investment in their products and solutions. 

39 
 
 
XML is language independent  
 

By being language independent, XML bypasses the requirement to have a standard binary 
encoding or storage format. Language independence also fosters immense interoperability 
amongst heterogeneous systems. It is also good for future compatilbilty. For example, if in the 
future a product needs to be changed in order to deal with a new computing paradigm or 
network protocol, by keeping XML flowing through the system, addition of a new layer to deal 
with this change is feasible.  

DOM and SAX are open, language‐independent set of interfaces  
 

By defining a set of programming language independent interfaces that allow the accessing and 
mutation of XML documents, the W3C made it easier for programmers to deal with XML. Not 
only does XML address the need for a standard information encoding and storage format, it 
also allows programmers a standard way to use that information. SAX is a very low level API, 
but it is more than what has been available before it. DOM is a higher level API that even 
provides a default object model for all XML documents (saving time in creating one from 
scratch if you are using data is document data). 
SAX, DOM and XML are very developer friendly because developers are going to decide 
whether this technology will be adopted by the majority and become a successful effort 
towards the goal of interoperable, platform, and device independent computing. 

XML is web enabled  
 

XML is derived from SGML, and so was HTML. So in essence, the current infrastructure available 
today to deal with HTML content can be re‐used to work with XML. This is a very big advantage 
towards delivering XML content using the software and networking infrastructure already in 
place today. This should be a big plus in considering XML for use in any of your projects, 
because XML naturally lends itself to being used over the web. 
Even if clients don’t support XML natively, it is not a big hindrance. In fact, Java with Servlets 
(on the server side) can convert XML with stylesheets to generate plain HTML that can be 
displayed in all web browsers. 
Using XML to pass parameters and return values on servers makes it very easy to allow these 
servers to be web‐enabled. A thin server side Java layer might be added that interacts with web 
browsers using HTML and translates the requests and responses from the client into XML, that 
is then fed into the server. 

XML is totally extensible  
 

By not predefining any tags in the XML Recommendation, the W3C allowed developers full 
control over customizing their data as they see fit. This makes XML very attractive to encoding 
data that already exists in legacy databases (by using database metadata, and other schema 

40 
 
 
information). This extensibility of XML makes it such a great fit when trying to get different 
systems to work with each other. 

XML supports shareable structure (using DTDs)  
 

Since the structure of the XML document can be specified in DTDs they provide a simple way to 
make it easier to exchange XML documents that conform to a DTD. For example, if two 
software systems need to exchange information, then if both of the systems conform to one 
DTD, the two systems can process information from each other. DTDs are not as powerful as 
some kind of schema architecture for XML, they don’t support typing, subclassing, or 
instantiation mechanisms that a schema architecture must have. 
DTDs are a simple way to make sure that 2 or more XML documents are of the same “type”. Its 
a very limited approach to making “typed” XML documents shareable across systems. In the 
future some kind of schema system will be proposed by the W3C that should allow typing, 
instantiation and inheritance of information (in XML). 

XML enables interoperability  
 

All of the advantages of XML outlined so far all make interoperability possible. This is one of the 
most important requirements for XML, to enable disparate systems to be able to share 
information easily.  
By taking the lowest common denominator approach, by being web enabled, protocol 
independent, network independent, platform independent and extensible, XML makes it 
possible for new systems and old systems (that are all different) to communicate with each 
other. Encoding information in plain text with tags is better than using propietary and platform 
dependent binary formats. 

Vision  
 

XML provides solutions for problems that have existed for the past 20 years. With most 
applications and software services using the Internet as a target platform for deployment, XML 
could not have come at a better time. With the web becoming so popular, a new paradigm of 
computing has emerged for which XML supplies one of the most important pieces, platform, 
vendor and application neutral data. Regardless of the programming language used to process 
XML, it will enable this new networked computing world. 
Java is also a key component of this new paradigm. On the server side, by working with XML, it 
can more naturally integrate legacy systems and services. With XML, Java can do what it does 
best, work very well on the server side, and web (and Internet) enable software systems. 

The advantages of XML over the HTML 
 
1) HTML is limited to a finite tags where as XML can have more customized tags 
2) Parsing a XML document is easier than an HTML document 

41 
 
 
3) XML can be used for pure XML pages as well as for embedding new kinds of 
contends in HTML , like the 
a) MathML ‐the mathematical mark up language is an XML application to 
include a mathematical equations in Web Pages. 
b) SMIL ‐ Synchronised Multimedia Integration language ‐is an XML 
application for including a timed Multimedia like the Slide shows and sub titled 
videos on web pages. 
where as HTML has no such feature , it can be used only to create a plain HTML 
document only. 
4) An XML document will have a DTD ( Document type Definition) which will impose 
conditions for a valid documents where as a HTML document has no such validation 
mechanism. 
 
Advantages of XML over HTML 
 
• By defining own markup language, can code documents more precisely  
• Reflects structure and semantics of documents ‐‐> better searching and navigation  
• Tagging/content separate from display  
• Allows single document to be used many ways  

Advantages of XML 

Using XML to exchange information offers many benefits, including the following: 

• Uses human, not computer, language. XML is readable (and understandable, even by 
novices) and no more difficult to code than HTML. 
• Completely compatible with Java and 100% portable. Any application that can process 
XML (on any platform) can use your information. 
• Extendable. Create your own tags (or use tags created by others) that use the native 
language of your domain, have the attributes you need, and make sense to you and 
your users. 

The following example illustrates, in a simplified way, the readability and extensibility of XML: 

HTML example  XML example 
<HTML>  <?XML VERSION="1.0" STANDALONE="yes" ?> 
<H1 ID="MN">State</H1>  <STATE STATEID="MN"> 
<H2 ID="12">City</H2>    <CITY CITYID="12"> 
<DL>      <NAME>Johnson</name> 
  <DT>Name</DT>      <POPULATION>5000</POPULATION> 
    <DD>Johnson</DD>    </CITY> 
  <DT>Population</DT>    <CITY CITYID="15"> 
    <DD>5000</DD>      <NAME>Pineville</NAME> 
</DL>      <POPULATION>60000</POPULATION> 
<H2 ID="15">City</H2>    </CITY> 

42 
 
 
<DL>    <CITY CITYID="20"> 
  <DT>Name</DT>      <NAME>Lake Bell</NAME> 
    <DD>Pineville</DD>      <POPULATION>20</POPULATION> 
  <DT>Population</DT>    </CITY> 
    <DD>60000</DD>  </STATE> 
</DL> 
<H2 ID="20">City</H2> 
<DL> 
  <DT>Name</DT> 
    <DD>Lake Bell</DD> 
  <DT>Population</DT> 
    <DD>20</DD> 
</DL> 
</HTML> 

HTML tag names reveal nothing about the meaning of their content. The example above uses 
an HTML definition list, but the problems inherent in using HTML would occur if the data were 
contained in a table or some other kind of HTML tags: For example: 

• Many the HTML tags are acronyms, so they are not as readable as common language. 
• HTML tags represent data (in this above example, city names and populations) as items 
to display, for example, as definitions in a list or cells in a table. This makes it difficult to 
manipulate the data or or exchange it between applications. 

The XML tag names are readable and convey the meaning of the data. Each XML tag 
immediately precedes the associated data, helping to make the information structure easily 
discerned by both humans and computers. The data structure follows a noticeable and useful 
pattern, making it easy to manipulate and exchange the data. 

Uses of XML 

XML has a variety of uses, including: 

• Web publishing: XML allows you to create interactive pages, allows the customer to 
customize those pages, and makes creating e‐commerce applications more intuitive. 
With XML, you store the data once and then render that content for different viewers or 
devices based on style sheet processing using an XSL/XSLT processor. 
• Web searching and automating Web tasks: XML defines the type of information 
contained in a document, making it easier to return useful results when searching the 
Web:  
o For example, using HTML to search for books authored by Tom Wolf is likely to 
return instances of the term 'wolf' outside of the context of author. Using XML 
restricts the search to the proper context (say, the information contained in the 
<author> tag) and returns only the desired type of information. Using XML, Web 
agents and robots (programs that automate Web searches or other tasks) will be 
more efficient and produce more useful results. 
43 
 
 
• General applications: XML provides a standard method to access information, making it 
easier for applications and devices of all kinds to use, store, transmit, and display data. 
• e‐business applications: XML implementations make electronic data interchange (EDI) 
more accessible for information interchange, business‐to‐business transactions, and 
business‐to‐consumer transactions. 
• Metadata applications: XML makes is easier to express metadata (Unified Modeling 
Language design models or user interface properties, for example) in a portable, 
reusable format. 
• Pervasive computing: XML provides portable and structured information types for 
display on pervasive (wireless) computing devices such as PDAs, cellular phones, and 
others.  
o For example, WML (Wireless Markup Language) and VoiceXML are currently 
evolving standards for describing visual and speech‐driven wireless device 
interfaces. 

Disadvantages of XML 

• More difficult, demanding, and precise than HTML  
• Lack of browser support/end user applications  
• Still experimental/not solidified 

Disadvantages of XML  
However, awesome XML is, there are some drawbacks which have hindered it from 
gaining widespread use since its inception. Let's look at the biggest drawback: The 
lack of adequate processing applications.  

For one, XML requires a processing application. That is, the nice thing about HTML 
was that you knew that if you wrote an HTML document, anyone, anywhere in the 
world, could read your document using Netscape. Well, with XML documents, that is 
not yet the case. There are no XML browsers on the market yet (although the latest 
version of IE does a pretty good job of incorporating XSL and XML documents 
provided HTML is the output).  

"While it's true that browser support is limited, IE 
5 and Netscape 5 are expected to fully support 
XML. Also, W3C's Amaya browser supports it 
today, as does the JUMBO browser that was 
created for the Chemical Markup Language.  

XML isn't about display ‐‐ it's about structure. This 
has implications that make the browser question 
secondary. So the whole issue of what is to be 
displayed and by what means is intentionally left 

44 
 
 

to other applications. You can target the same 
XML (with different XSL) for different devices 
(standard web browser, palm pilot, printer, etc.). 
You should not get the impression that XML is 
useless until browsers support it. This is definitely 
not true ‐‐ we are using it at NASA in ways where 
no browser plays any role." ‐ Ken Sall  

Thus, XML documents must either be converted into HTML before distribution or 
converting it to HTML on‐the‐fly by middleware. Barring translation, developers must 
code their own processing applications.  
The most common tactic used now is to write parsing routines in DHTML or Java, or 
Server‐Side perl to parse through an XML document, apply the formatting rules 
specified by the style sheet, and "convert" it all to HTML.  
However, this takes some magic and the amount of work necessary even to print 
"hello world" are sometimes enough to dissuade developers from adopting the 
technology.  
Nevertheless, parsing algorithms and tools continue to improve over time as more 
and more people see the long‐term benefits of migrating their data to XML. The 
backend part of XML will continue to become simpler and simpler. Already Internet 
Explorer and Netscape provide a decent amount of built in XML parsing tools.  
 
 
 
 
 
 
 
EDI –ELECTRONIC DATA INTERCHANGE 
 
Short for Electronic Data Interchange, the transfer of data between different companies using 
networks, such as VANs or the Internet. As more and more companies get connected to the 
Internet, EDI is becoming increasingly important as an easy mechanism for companies to buy, 
sell, and trade information. ANSI has approved a set of EDI standards known as the X12 
standards. 
 
AdvantagesofXMLoverEDI 
 
  Explicit structure 
  Easier validation 
  Can easily use the Internet 
  Cheaper to implement 
  Can open up electronic commerce to small and medium‐size businesses (social agenda again) 
 

45 
 
 
Electronic Data Interchange (EDI) refers to the structured transmission of data between 
organizations by electronic means. It is used to transfer electronic documents from one 
computer system to another, i.e. from one trading partner to another trading partner. It is 
more than mere E‐mail; for instance, organizations might replace bills of lading and even 
Cheques with appropriate EDI messages. It also refers specifically to a family of standards, 
including the X12 series. However, EDI also exhibits its pre‐Internet roots, and the standards 
tend to focus on ASCII (American Standard Code for Information Interchange)‐formatted single 
messages rather than the whole sequence of conditions and exchanges that make up an inter‐
organization business process. 
Electronic data interchange (EDI) is the electronic movement of data between or within 
organizations in a structured, computer‐retrievable data format that permits information to be 
transferred from a computer program in one location to a computer program in another 
location without rekeying. EDI includes the direct transmission of data between locations; 
transmission using an intermediary such as a communication network; and the exchange of 
computer tapes, disks, or other digital storage devices. In many cases, content‐related error 
checking and some degree of processing of the information are also involved. EDI differs from 
electronic mail in that an actual transaction is transmitted electronically, rather than a simple 
message consisting primarily of text. 
EDI is used for electronic funds transfer (EFT) between financial institutions, which facilitates 
such common transactions as the direct deposit of payroll checks by employers, the direct debit 
of consumer accounts to make mortgage or utility payments, and the electronic payment of 
federal taxes by businesses. Another common application of EDI involves the direct exchange of 
standard business transaction documents—such as purchase orders, invoices, and bills of 
lading—from one business to another via computer. EDI is also used by retail businesses as part 
of their electronic scanning and point‐of‐sale (POS) inventory replenishment systems. Overall, 
EDI offers a number of benefits to businesses and—thanks to the rapid evolution of the related 
technology—is becoming more readily available to small businesses all the time. 
 
Benefits of Edi 
 
"EDI saves money and time because transactions can be transmitted from one information 
system to another through a telecommunications network, eliminating the printing and 
handling of paper at one end and the inputting of data at the other," Kenneth C. Laudon and 
Jane Price Laudon wrote in their book Management Information Systems: A Contemporary 
Perspective. "EDI may also provide strategic benefits by helping a firm 'lock in' customers, 
making it easier for customers or distributors to order from them rather than from 
competitors." EDI was developed to solve the problems inherent in paper‐based transaction 
processing and in other forms of electronic communication. In solving these problems, EDI is a 
tool that enables organizations to reengineer information flows and business processes. It 
directly addresses several problems long associated with paper‐based transaction systems: 
• Time delays—Paper documents may take days to transport from one location to 
another, while manual processing methodologies necessitate steps like keying and filing 
that are rendered unnecessary through EDI. 
• Labor costs—In non‐EDI systems, manual processing is required for data keying, 
document storage and retrieval, sorting, matching, reconciling, envelope stuffing, 
stamping, signing, etc. While automated equipment can help with some of these 
46 
 
 
processes, most managers will agree that labor costs for document processing represent 
a significant proportion of their overhead. In general, labor‐based processes are much 
more expensive in the long term EDI alternatives. 
• Accuracy—EDI systems are more accurate than their manual processing counterparts 
because there are fewer points at which errors can be introduced into the system. 
• Information Access—EDI systems permit myriad users access to a vast amount of 
detailed transaction data in a timely fashion. In a non‐EDI environment, in which 
information is held in offices and file cabinets, such dissemination of information is 
possible only with great effort, and it cannot hope to match an EDI system's timeliness. 
Because EDI data is already in computer‐retrievable form, it is subject to automated 
processing and analysis. It also requires far less storage space. 
 
Infrastructure for Edi 
Several elements of infrastructure must exist in order to introduce an EDI system, including: 1) 
format standards to facilitate automated processing by all users, 2) translation software to 
translate from a user's proprietary format for internal data storage into the generic external 
format and back again, 3) value‐added networks to solve the technical problems of sending 
information between computers, 4) inexpensive microcomputers to bring all potential users—
even small ones—into the market, and 5) procedures for complying with legal rules. It has only 
been in the past several years that all of these ingredients have fallen into place. 
 
FORMAT STANDARDS. To permit the efficient use of computers, information must be highly 
organized into a consistent data format. A format defines how information in a message is 
organized: what data goes where, what data is mandatory, what is optional, how many 
characters are permitted for each data field, how data fields are ordered, and what codes or 
abbreviations are permitted. 
Early EDI efforts in the 1960s used proprietary formats developed by one firm for exclusive use 
by its trading partners. This worked well until a firm wanted to exchange EDI documents with 
other firms who wanted to use their own formats. Since the different formats were not 
compatible, data exchange was difficult if not impossible. To facilitate the widespread use of 
EDI, standard formats were developed so that an electronic message sent by one party could be 
understood by any receiver that subscribes to that format standard. In the United States the 
Transportation Data Coordinating Committee began in 1968 to design format standards for 
transportation documents. The first document was approved in 1975. This group pioneered the 
ideas that are used by all standards organizations today. 
North American standards are currently developed and maintained by a volunteer organization 
called ANSI (American National Standards Institute). The format for a document defined by 
ANSI is broad enough to satisfy the needs of many different industries. Electronic documents 
are typically of variable length and most of the information is optional. When a firm sends a 
standard EDI purchase order to another firm, it is possible for the receiving firm to pass the 
purchase order data through an EDI translation program directly to a business application 
without manual intervention. In the late 1990s, international format standards were 
established and introduced as well to facilitate international business activity. 
 
TRANSLATION SOFTWARE. Translation software makes EDI work by translating data from the 
sending firm's internal format into a generic EDI format. Translation software also receives a 
47 
 
 
sender's EDI message and translates it from the generic standard into the receiver's internal 
format. There are currently translation software packages for almost all types of computers and 
operating systems. 
 
VALUE‐ADDED NETWORKS (VANS). When firms first began using EDI, most communications of 
EDI documents were directly between trading partners. Unfortunately, direct computer‐to‐
computer communications requires that both firms 1) use similar communication protocols, 2) 
have the same transmission speed, 3) have phone lines available at the same time, and 4) have 
compatible computer hardware. If these conditions are not met, then communication becomes 
difficult if not impossible. A value‐added network (VAN) can solve these problems by providing 
an electronic mailbox service. By using a VAN, an EDI sender need only learn to send and 
receive messages to or from one party: the VAN. Since a VAN provides a very flexible computer 
interface, it can talk to virtually any type of computer. This means that to conduct EDI with 
hundreds of trading partners, an organization only has to talk to one party. In addition, VANs 
provide important security elements for dissemination of information between parties. 
 
INEXPENSIVE COMPUTERS. The fourth building block of EDI is inexpensive computers that 
permit even small firms to implement EDI. Since microcomputers are now so prevalent, it is 
possible for firms of all sizes to deal with each other using EDI. 
 
PROCEDURES FOR COMPLYING WITH LEGAL RULES. Legal rules apply to the documents that 
accompany a wide variety of business transactions. For example, some contracts must include a 
signature or must be an original in order to be legal. If documents are to be transmitted via EDI, 
companies must establish procedures to verify that messages are authentic and that they 
comply with the agreed‐upon protocol. In addition, EDI requires companies to institute error‐
checking procedures as well as security measures to prevent unauthorized use of their 
computer systems. Still, it is important to note that some sorts of business documents—such as 
warranties or limitations of liability—are difficult to transmit legally using EDI. 

 
EDI is considered to be a technical representation of a business conversation between two 
entities, either internal or external. Note, there is a perception that "EDI" constitutes the entire 
electronic data interchange paradigm, including the transmission, message flow, document 
format, and software used to interpret the documents. EDI is considered to describe the 
rigorously standardized format of electronic documents.EDI is very useful in supply chain. 
The EDI standards were designed to be independent of communication and software 
technologies. EDI can be transmitted using any methodology agreed to by the sender and 
recipient. This includes a variety of technologies, including modem (asynchronous, and 
bisynchronous), FTP, E‐mail, HTTP, AS1, AS2, etc. It is important to differentiate between the 
EDI documents and the methods for transmitting them. When they compared the 
bisynchronous protocol 2400 bit/s modems, CLEO devices, and value‐added networks used to 
transmit EDI documents to transmitting via the Internet, some people equated the non‐Internet 
technologies with EDI and predicted erroneously that EDI itself would be replaced along with 
the non‐Internet technologies. These non‐internet transmission methods are being replaced by 
Internet Protocols such as FTP, telnet, and E‐mail, but the EDI documents themselves still 
remain. 
48 
 
 
 
There are four major sets of EDI standards: 
 
• The UN‐recommended UN/EDIFACT is the only international standard and is 
predominant outside of North America. 
• The US standard ANSI ASC X12 (X12) is predominant in North America. 
• The TRADACOMS standard developed by the ANA (Article Numbering Association) is 
predominant in the UK retail industry. 
• The ODETTE standard used within the European automotive industry 
• 1. Name of Standard. Electronic Data Interchange (EDI) (FIPS PUB 161‐2).  
• 2. Category of Standard. Electronic Data Interchange.  
• 3. Explanation.  
• 3.1. Definition and Use of EDI. EDI is the computer‐to‐computer interchange of strictly 
formatted messages that represent documents other than monetary instruments. EDI 
implies a sequence of messages between two parties, either of whom may serve as 
originator or recipient. The formatted data representing the documents may be 
transmitted from originator to recipient via telecommunications or physically 
transported on electronic storage media.  
• In EDI, the usual processing of received messages is by computer only. Human 
intervention in the processing of a received message is typically intended only for error 
conditions, for quality review, and for special situations. For example, the transmission 
of binary or textual data is not EDI as defined here unless the data are treated as one or 
more data elements of an EDI message and are not normally intended for human 
interpretation as part of on‐line data processing.  
• An example of EDI is a set of interchanges between a buyer and a seller. Messages from 
buyer to seller could include, for example, request for quotation (RFQ), purchase order, 
receiving advice and payment advice; messages from seller to buyer could include, simi‐ 
larly, bid in response to RFQ, purchase order acknowledgment, shipping notice and 
invoice. These messages may simply provide information, e.g., receiving advice or 
shipping notice, or they may include data that may be interpreted as a legally binding 
obligation, e.g., bid in response to RFQ or purchase order.  
• EDI is being used also for an increasingly diverse set of concerns, for example, for 
interchanges between healthcare providers and insurers, for travel and hotel bookings, 
for education administration, and for government regulatory, statistical and tax 
reporting.  
• 3.2. Standards Required for EDI. From the point of view of the standards needed, EDI 
may be defined as an interchange between computers of a sequence of standardized 
messages taken from a predetermined set of message types. Each message is 
composed, according to a standardized syntax, of a sequence of standardized data 
elements. It is the standardization of message formats using a standard syntax, and the 
standardization of data elements within the messages, that makes possible the 
assembling, disassembling, and processing of the messages by computer.  
• Implementation of EDI requires the use of a family of interrelated standards. Standards 
are required for, at minimum: (a) the syntax used to compose the messages and 
separate the various parts of a message, (b) types and definitions of application data 
elements, most of variable length, (c) the message types, defined by the identification 
49 
 
 
and sequence of data elements forming each message, and (d) the definitions and 
sequence of control data elements in message headers and trailers.  
• Additional standards may define: (e) a set of short sequences of data elements called 
data segments, (f) the manner in which more than one message may be included in a 
single transmission, and (g) the manner of adding protective measures for integrity, 
confidentiality, and authentication into transmitted messages. 
• 3.3. Limited Coverage of this Standard. This FIPS covers only EDI. It does not cover 
other forms of electronic interchange, for example, systems of interchange that do not 
consist of messages taken from a predetermined set. Additionally, an interchange 
application including only one or two predetermined message types using only fixed‐
length data elements is excluded from coverage of this FIPS. This FIPS also is not 
intended to cover transmissions from medical, laboratory, or environment‐sensing 
instrumentation.  
• 3.4. The Long‐Range Goal for EDI Standards. There are several different EDI standards 
in use today, but the achievement of a single universally‐used family of EDI standards is 
a long‐range goal. A single universally‐used family of standards would make use of EDI 
more efficient and minimize aggregate costs of use. Specifically, it would (a) minimize 
needs for training of personnel in use and maintenance of EDI standards, (b) eliminate 
duplication of functionality and the costs of achieving that duplication now existing in 
different systems of standards, (c) minimize requirements for different kinds of 
translation software, and (d) allow for a universal set of data elements that would ease 
the flow of data among different but interconnected applications, and thereby maximize 
useful information interchange.  
• This FIPS PUB recognizes the reality that some families of EDI standards were developed 
to provide solutions to immediate needs, and that inclusion of the goal of universality in 
their development would have unacceptably delayed their availability. However, a 
future is envisioned in which the benefits of universality outweigh the sunk costs in 
specialized solutions, leading first to cooperation among standards developers, then to 
harmonization of standards, and eventually to a single universally accepted family of EDI 
standards.  
• 3.5. Adoption of Specific Families of Standards. This FIPS PUB adopts, with specific 
conditions specified below, the families of EDI standards known as X12, UN/EDIFACT 
and HL7. This FIPS PUB does not mandate the implementation of EDI systems within the 
Federal Government; rather it requires the use of the identified families of standards 
with specified constraints when Federal departments or agencies implement EDI 
systems.  

 
 
 
 
DATA BASE IN XML 
 
Similarities with Database 
 
! Storage: Tables vs. XML documents 
50 
 
 
! Schemas: Database schema vs. DTD, XML schema languages 
! Query languages: SQL vs. XQL, XML‐QL, QUILT 
! Programming interface: JDBC vs.SAX, DOM 
Differences from Database 
! Storage mechanism 
! Indexing 
! Built‐in security 
! Transaction support 
! Data integrity 
! Multi‐user access 
! Query across multiple data sources 
XML Database Types 
 
XML enabled database 
 
"XML is used for input and output 
"Relational tables internally 
"Middleware converts between XML and relational database tables 
Pros 
"Proven database technology 
 Cons 
"Conversion between XML and relational tables is needed 
# Conversion performance overhead 
# Complex XML hierarchy information is hard to convert to tables 
# Round‐tripping to exactly same document is hard  
"Might not handle Unicode well enough 
 
Native XML database 
"XML data is stored in its native format 
Pros 
"Preserves the XML hierarchy information 
Cons 
"Not proven yet 
"Scalability concern 
! When to use 
"to integrate information from many different platforms and formats and send it 
to business partners or customers 
 
Mapping XML Structure to DB Structure 
 
! Template‐driven mapping 
! Model‐driven mapping 
"Table model 
"Data‐specific object model 
 
Template‐driven Mapping 
51 
 
 
! No predefined mapping 
! Embed commands in a template 
! Pocessed by middleware 
! Very flexible 
 
Model‐Driven Mapping 
 
! Data model is imposed on the structure of the XML document 
! Not as flexible as Template‐model 
"Typically used with XSLT to compensateIt  
! Simple 
! Two models 
"Table model 
"Data‐specific object model 
 
Issues of Storing XML data into Relational Database 
 
! Data types 
! Binary data 
! Character set 
! Processing instruction 
! Storing markup 
! DTD generation from DB schema and vice versa 
Data Types 
! All data in XML document is text "Need to be translated to datatypes of 
database 
! Issues 
"Translation is not always easy 
Binary Data 
! Two ways of storing binary data in XML document 
"Unparsed entities 
"Base64 encoding 
! Issues 
"No XML standard notation for Base64‐encoded data 
"Application specific notation is needed 
# Could be lost during translation 
Character Set 
! Unicode is native encoding scheme of XML document 
! Issues 
"Databases might not support Unicode 
Storing Markup 
! Storing markup information of XML document could be useful 
! Issues 
"Metadata describing markup data need to be created and maintained 
Advanced Features 
! Indexing when storing XML documents 
52 
 
 
"Allows faster search 

 
An XML database is a data persistence software system that allows data to be stored in XML 
format. This data can then be queried, exported and serialized into the desired format. 
Two major classes of XML database exist: 
1. XML‐enabled: these map all XML to a traditional database (such as a relational 
database[1]), accepting XML as input and rendering XML as output. This term implies 
that the database does the conversion itself (as opposed to relying on middleware). 
2. Native XML (NXD): the internal model of such databases depends on XML and uses XML 
documents as the fundamental unit of storage, which are, however, not necessarily 
stored in the form of text files. 
Rationale for XML in databases 
O'Connell (2005, 9.2) gives one reason for the use of XML in databases: the increasingly 
common use of XML for data transport, which has meant that "data is extracted from 
databases and put into XML documents and vice‐versa". It may prove more efficient (in terms 
of conversion costs) and easier to store the data in XML format. 
Native XML databases 
The term "native XML database" (NXD) can lead to confusion. Many NXDs do not function as 
standalone databases at all, and do not really store the native (text) form. 
The formal definition from the XML:DB initiative states that a native XML database:[2] 
• Defines a (logical) model for an XML document — as opposed to the data in that 
document — and stores and retrieves documents according to that model. At a 
minimum, the model must include elements, attributes, PCDATA, and document order. 
Examples of such models include the XPath data model, the XML Infoset, and the 
models implied by the DOM and the events in SAX 1.0. 
• Has an XML document as its fundamental unit of (logical) storage, just as a relational 
database has a row in a table as its fundamental unit of (logical) storage. 
• Need not have any particular underlying physical storage model. For example, NXDs can 
use relational, hierarchical, or object‐oriented database structures, or use a proprietary 
storage format (such as indexed, compressed files). 
53 
 
 
XML representation of a relational database  
A relational database consists of a set of tables, where each table is a set of records. A record in 
turn is a set of fields and each field is a pair field‐name/field‐value. All records in a particular 
table have the same number of fields with the same field‐names.  

This article describes an application of (a simple subset of) XML that can be used to represent 
such a database.  
The relational data‐model also defines certain constraints on the tables and defines operations 
on them. We are not concerned with the constraints and operations here. In other words, we 
are not trying to create a query language or a data‐definition language, just a language that 
captures the data in a database or in a particular view of the database.  
Several such languages are possible, of course, and it not hard to come up with alternative and 
equally valid ones as the one described below.  

Introduction  

The description of the database above suggests a simple nesting of fields inside records inside 
tables inside databases. Here is an example of a single database with two tables:  

<!doctype mydata "http://www.w3.org/mydata"> 
<mydata> 
 
<authors> 
<author> 
<name>Robert Roberts</name> 
<address>10 Tenth St, Decapolis</address> 
<editor>Ella Ellis</editor> 
<ms type="blob">ftp://docs/rr‐10</ms> 
<born>1960/05/26</born> 
</author> 
 
<author> 
<name>Tom Thomas</name> 
<address>2 Second Av, Duo‐Duo</address> 
<editor>Ella Ellis</editor> 
<ms type="blob">ftp://docs/tt‐2</ms> 
</author> 
 
<author> 
<name>Mark Marks</name> 
<address>1 Premier, Maintown</address> 
<editor>Ella Ellis</editor> 
<ms type="blob">ftp://docs/mm‐1</ms> 
</author> 
</authors> 
 
54 
 
 
<editors> 
<editor> 
<name>Ella Ellis</name> 
<telephone>7356</telephone> 
</editor> 
</editors> 
 
</mydata> 

The format is verbose, since XML is verbose. On the other hand, it compresses well with 
standard compression tools. It is also easy to print the database (or a part of it) with standard 
XML browsers and a simple style sheet.  

The database  

A relational can be modeled as a hierarchy of depth four: the database consists of a set of 
tables, which in turn consist of records, which in turn consist of fields.  
We can model the database with a document node and its associated element node:  

<!doctype name "url"> 
<name> 
table1 
table2 
... 
tablen 
</name>  

The name is arbitrary. The url is optional, but can be used to point to information about the 
database. We don't define what it points to. [Or should we?]  
The order of the tables is also arbitrary, since a relational database defines no ordering on 
them.  

The table  

Each table of the database is represented by an element node with the records as its children:  

<name> 
record1 
record2 
... 
recordm 
</name>  

The name is the name of the table. The order of the records is arbitrary, since the relational 
data model defines no ordering on them.  

55 
 
 
The record  

A record is also represented by an element node, with its fields as children:  

<name> 
field1 
field2 
... 
fieldm 
</name>  

The name is arbitrary, since the relational data model doesn't define a name for a record type. 
However, in XML it cannot be omitted. One scheme is to re‐use the name of the table, or, if the 
table has a name that is a plural, to use the singular form (`persons' ‐> `person', `parts' ‐> 
`part').  
The order of the fields is again immaterial.  

The field  

A field is represented as an element node with a data node as its only child:  

<name type="t"> 

</name  

If d is omitted, it means the value of the fields is the empty string.  
The value of t indicates the type of the value (such as string, number, boolean, date). [Should 
we give a complete list?] If the type attribute is omitted, the type is assumed to be `string.'  

Null values  

Null values are represented by the absence of the field.  
Note that this is different from leaving the field empty, which indicates that the field contains a 
string of length zero. Null values have special properties in relational databases. For example, 
two fields both with null values are not equal (in contrast to two fields with zero‐length strings, 
which are).  

Strong typing  

Tim Bray has written a proposal for adding strong typing to XML, using a set of fixed attributes. 
The above example would get attributes declared as follows:  

<!doctype mydata "http://www.w3.org/mydata"> 
<mydata> 
 
<authors> 

56 
 
 
<?xml default name 
    xml‐sqltype="varchar" 
    xml‐sqlsize="40" 
?> 
<?xml default address 
    xml‐sqltype="varchar" 
    xml‐sqlsize="40" 
?> 
... 
<?xml default born 
    xml‐sqltype="date" 
    xml‐sqlmin="1900/01/01" 
    xml‐sqlmax="1990/01/01" 
?> 
... 
</authors> 
 
<editors> 
<?xml default name 
    xml‐sqltype="varchar" 
    xml‐sqlsize="40" 
?> 
... 
</editors> 
 
</mydata> 

etc. This will allow an application that knows about these attributes to check the content of 
each field.  

 
 

Introduction: XML and Data 

XML stands for eXtensible Markup Language. XML is a meta‐markup language developed by the 
World Wide Web Consortium(W3C) to deal with a number of the shortcomings of HTML. As 
more and more functionality was added to HTML to account for the diverse needs of users of 
the Web, the language began to grow increasingly complex and unwieldy. The need for a way 
to create domain‐specific markup languages that did not contain all the cruft of HTML became 
increasingly necessary and XML was born. 
The main difference between HTML and XML is that whereas in HTML the semantics and syntax 
of tags is fixed, in XML the author of the document is free to create tags whose syntax and 
semantics are specific to the target application. Also the semantics of a tag is not tied down but 
is instead dependent on the context of the application that processes the document. The other 

57 
 
 
significant differences between HTML and XML is that the an XML document must be well‐
formed. 
Although the original purpose of XML was as a way to mark up content, it became clear that 
XML also provided a way to describe structured data thus making it important as a data storage 
and interchange format. XML provides many advantages as a data format over others, 
including: 

1. Built in support for internationalization due to the fact that it utilizes unicode.  
2. Platform independence (for instance, no need to worry about endianess).  
3. Human readable format makes it easier for developers to locate and fix errors than with 
previous data storage formats.  
4. Extensibility in a manner that allows developers to add extra information to a format 
without breaking applications that where based on older versions of the format.  
5. Large number of off‐the‐shelf tools for processing XML documents already exist.  
The world of traditional data storage and XML have never been closer together. To better 
understand how data storage and retrievel works in an XML world, this paper will first discuss 
the past, present, and future of structuring XML documents. Then we will delve into the 
languages that add the ability to query an XML document similar to a traditional data store. This 
will be followed by an exploration of how the most popular RDBMSs have recognized the 
importance of this new data storage format and have integrated XML into their latest releases. 
Finally the rise of new data storage and retrieval systems specifically designed for handling XML 
will be shown.  

Structuring XML: DTDs and XML Schemas 

Since XML is a way to describe structured data there should be a means to specify the structure 
of an XML document. Document Type Definitions (DTDs) and XML Schemas are different 
mechanisms that are used to specify valid elements that can occur in a document, the order in 
which they can occur and constrain certain aspects of these elements. An XML document that 
conforms to a DTD or schema is considered to be valid. Below is listing of the different means of 
constraining the contents of an XML document. 

 SAMPLE XML FRAGMENT 
  
  <gatech_student gtnum="gt000x"> 
   <name>George Burdell</name> 
   <age>21</age> 
  </gatech_student> 
 

1. Document Type Definitions (DTD): DTDs were the original means of specifying the 
structure of an XML document and a holdover from XML's roots as a subset of the 
Standardized and General Markup Language(SGML). DTDs have a different syntax from 
XML and are used to specify the order and occurence of elements in an XML document. 
Below is a DTD for the above XML fragment.  
2.  DTD FOR SAMPLE XML FRAGMENT 

58 
 
 
3.  
4.   <!ELEMENT gatech_student (name, age)> 
5.   <!ATTLIST gatech_student gtnum CDATA> 
6.   <!ELEMENT name (#PCDATA)> 
7.   <!ELEMENT age (#PCDATA)> 
8.  

The DTD specifies that the gatech_student element has two child elements, name and 
age, that contain character data as well as a gtnum attribute that contains character 
data. 
9. XML Data Reduced (XDR): DTDs proved to be inadequate for the needs of users of XML 
due to to a number of reasons. The main reasons behind the criticisms of DTDs were the 
fact that they used a different syntax than XML and their non‐existent support for 
datatypes. XDR, a recommendation for XML schemas, was submitted to the W3C by the 
Microsoft Corporation as a potential XML schema standard which but was eventually 
rejected. XDR tackled some of the problems of DTDs by being XML based as well as 
supporting a number of datatypes analogous to those used in relational database 
management systems and popular programming languages. Below is an XML schema, 
using XDR, for the above XML fragment.  
10.  XDR FOR SAMPLE XML FRAGMENT 
11.  
12.   <Schema name="myschema" xmlns="urn:schemas‐microsoft‐com:xml‐data" 
13.                         xmlns:dt="urn:schemas‐microsoft‐com:datatypes"> 
14.    <ElementType name="age" dt:type="ui1" /> 
15.    <ElementType name="name" dt:type="string" /> 
16.    <AttributeType name="gtnum" dt:type="string" /> 
17.    <ElementType name="gatech_student" order="seq"> 
18.     <element type="name" minOccurs="1" maxOccurs="1"/> 
19.     <element type="age" minOccurs="1" maxOccurs="1"/>   
20.     <attribute type="gtnum" /> 
21.    </ElementType> 
22.   </Schema> 
23.  

The above schema specifies types for a name element that contains a string as its 
content, an age element that contains an unsigned integer value of size one byte (i.e. 
btw 0 and 255), and a gtnum attribute that is a string value. It also specifies a 
gatech_student element that has one occurence each of a name and an age element in 
sequence as well as a gtnum attribute. 
24. XML Schema Definitions (XSD) : The W3C XML schema recommendation provides a 
sophisticated means of describing the structure and constraints on the content model of 
XML documents. W3C XML schema support more datatypes than XDR, allow for the 
creation of custom data types, and support object oriented programming concepts like 
inheritance and polymorphism. Currently XDR is used more widely than than W3C XML 
schema but this is primarily because the XML Schema recommendation is fairly new and 
will thus take time to become accepted by the software industry.  
59 
 
 
25.  XSD FOR SAMPLE XML FRAGMENT 
26.  
27.   <schema xmlns="http://www.w3.org/2001/XMLSchema" >  
28.    <element name="gatech_student"> 
29.     <complexType> 
30.      <sequence> 
31.       <element name="name" type="string"/> 
32.       <element name="age" type="unsignedInt"/>     
33.      </sequence> 
34.      <attribute name="gtnum"> 
35.       <simpleType> 
36.        <restriction base="string"> 
37.         <pattern value="gt\d{3}[A‐Za‐z]{1}"/> 
38.        </restriction> 
39.       </simpleType> 
40.      </attribute> 
41.     </complexType> 
42.    </element> 
43.   </schema> 
44.  

The above schema specifies a gatech_student complex type (meaning it can have 
elements as children) that contains a name and an age element in sequence as well as a 
gtnum attribute. The name element has to have a string as content, the age attribute 
has an unsigned integer value while the gtnum element has to be matched by a regular 
expression that matches the letters "gt" followed by 3 digits and a letter. 
The above examples show that DTDs give the least control over how one can constrain and 
structure data within an XML document while W3C XML schemas give the most.  

XML Querying: XPath and XQuery 
It is sometimes necessary to extract subsets of the data stored within an XML document. A 
number of languages have been created for querying XML documents including Lorel, Quilt, 
UnQL, XDuce, XML‐QL, XPath, XQL, XQuery and YaTL. Since XPath is already a W3C 
recommendation while XQuery is on its way to becoming one, the focus of this section will be 
on both these languages. Both languages can be used to retrieve and manipulate data from an 
XML document.  
1. XML Path Language (XPath): XPath is a language for addressing parts of an XML 
document that utilizes a syntax that resembles hierarchical paths used to address parts 
of a filesystem or URL. XPath also supports the use of functions for interacting with the 
selected data from the document. It provides functions for the accessing information 
about document nodes as well as for the manipulation of strings, numbers and 
booleans. XPath is extensible with regards to functions which allows developers to add 
functions that manipulate the data retrieved by an XPath query to the library of 
functions available by default. XPath uses a compact, non‐XML syntax in order to 
facilitate the use of XPath within URIs and XML attribute values (this is important for 
other W3C recommendations like XML schema and XSLT that use XPath within 

60 
 
 
attributes). 
 
XPath operates on the abstract, logical structure of an XML document, rather than its 
surface syntax. XPath is designed to operate on a single XML document which it views as 
a tree of nodes and the values returned by an XPath query are considered conceptually 
to be nodes. The types of nodes that exist in the XPath data model of a document are 
text nodes, element nodes, attribute nodes, root nodes, namespace nodes, processing 
instruction nodes, and comment nodes. 
 
Sample XPath Queries Against Sample XML Fragment  
a. /gatech_student/name 

Selects all name elements that are children of the root element gatech_student. 

b. //age 

Selects all age elements in the document. 

c. /gatech_student/* 

Selects all child elements of the root element gatech_student. 

d. /gatech_student[@gtnum] 

Selects all gtnum attributes of the gatech_student elements in the document. 

e. //*[name()='age'] 

Selects all elements that are named "age". 

f. /gatech_student/age/ancestor::* 

Selects all ancestors of all the age elements that are children of the 
gatech_student element (which should select the gatech_student element). 
2.  
3. XML Query Language (XQuery): XQuery is an attempt to provide a query language that 
provides the same breadth of functionality and underlying formalism as SQL does for 
relational databases. XQuery is a functional language where each query is an expression. 
XQuery expressions fall into seven broad types; path expressions, element constructors, 
FLWR expressions, expressions involving operators and functions, conditional 
expressions, quantified expressions or expressions that test or modify datatypes. The 
syntax and semantics of the different kinds of XQuery expressions vary significantly 
which is a testament to the numerous influences in the design of XQuery. 
 
XQuery has a sophisticated type system based on XML schema datatypes and supports 
the manipulation of the document nodes unlike XPath. Also the data model of XQuery is 

61 
 
 
not only designed to operate on a single XML document but also a well‐formed 
fragment of a document, a sequence of documents, or a sequence of document 
fragments. 
 
W3C is also working towards creating an alternate version of XQuery that has the same 
semantics but uses XML based syntax instead called XQueryX. 
 
Sample XQuery Queries and Expressions Taken From W3C Working Draft  
a. path expressions: XQuery supports path expressions that are a superset of those 
currently being proposed for the next version of XPath. 
i. //emp[name="Fred"]/salary * 12 
 
From a document that contains employees and their monthly salaries, 
extract the annual salary of the employee named "Fred". 
ii. document("zoo.xml")//chapter[2 TO 5]//figure 
 
Find all the figures in chapters 2 through 5 of the document named 
"zoo.xml." 
b. element constructors: In some situations, it is necessary for a query to create or 
generate elements. Such elements can be embeded directly into a query in an 
expression called an element constructor. 

i.       <emp empid = {$id}> 
ii.              {$name}  
iii.              {$job} 
iv.        </emp> 
v. Generate an <emp> element that has an "empid" attribute. The value of 
the attribute and the content of the element are specified by variables 
that are bound in other parts of the query. 
c. FLWR expressions: A FLWR (pronounced "flower") expression is a query 
construct composed of FOR, LET, WHERE, and a RETURN clauses. A FOR clause is 
an iteration construct that binds a variable to a sequence of values returned by a 
query (typically a path expression). A LET clause similarly binds variables to 
values but instead of a series of bindings only one occurs similar to an 
assignment statement in a programming language. A WHERE clause contains one 
or more predicates that are used on the nodes returned by preceding LET or FOR 
clauses. The RETURN clause generates the output of the FLWR expression, which 
may be any sequence of nodes or primitive values. The RETURN clause is 
executed once for each node returned by the FOR and LET clauses that passes 
the WHERE clause. The results of these multiple executions is concatenated and 
returned as the result of the expression. 

i.        FOR $b IN document("bib.xml")//book 
ii.         WHERE $b/publisher = "Morgan Kaufmann" 
iii.         AND $b/year = "1998" 
iv.         RETURN $b/title 

62 
 
 
v. List the titles of books published by Morgan Kaufmann in 1998. 

vi.        <big_publishers> 
vii.            { 
viii.              FOR $p IN distinct(document("bib.xml")//publisher) 
ix.              LET $b := document("bib.xml")//book[publisher = $p] 
x.              WHERE count($b) > 100 
xi.              RETURN $p 
xii.            } 
xiii.         </big_publishers> 
xiv. List the publishers who have published more than 100 books. 
d. conditional expressions: A conditional expression evaluates a test expression 
and then returns one of two result expressions. If the value of the test 
expression is true, the value of the first result expression is returned otherwise, 
the value of the second result expression is returned. 

i.        FOR $h IN //holding 
ii.         RETURN 
iii.           <holding> 
iv.             {$h/title, 
v.              IF ($h/@type = "Journal") 
vi.              THEN $h/editor 
vii.              ELSE $h/author 
viii.             } 
ix.           </holding> 
x.          SORTBY (title) 
xi.         
xii. Make a list of holdings, ordered by title. For journals, include the editor, 
and for all other holdings, include the author. 
e. quantified expressions: XQuery has constructs that are equivalent to quantifiers 
used in mathematics and logic. The SOME clause is an existential quantifier used 
for testing to see if a series of values contains at least one node that satisfies a 
predicate. The EVERY clause is a universal quantifier used to test to see if all 
nodes in a series of values satisfy a predicate. 

i.        FOR $b IN //book 
ii.         WHERE SOME $p IN $b//para SATISFIES 
iii.            (contains($p, "sailing") AND contains($p, "windsurfing")) 
iv.         RETURN $b/title 
v.         
vi. Find titles of books in which both sailing and windsurfing are mentioned 
in the same paragraph. 

vii.        FOR $b IN //book 
viii.         WHERE EVERY $p IN $b//para SATISFIES 
ix.            contains($p, "sailing")  
x.         RETURN $b/title 
63 
 
 
xi.         
xii. Find titles of books in where sailing is mentioned in every paragraph. 
f. expressions involving user defined functions: Besides providing a core library of 
functions similar to those in XPath, XQuery also allows user defined functions to 
be used to extend the core function library.  
i.       NAMESPACE xsd = "http://www.w3.org/2001/XMLSchema" 
ii.  
iii.        DEFINE FUNCTION depth($e) RETURNS xsd:integer  
iv.        { 
v.          # An empty element has depth 1 
vi.          # Otherwise, add 1 to max depth of children 
vii.         IF (empty($e/*)) THEN 1 
viii.         ELSE max(depth($e/*)) + 1 
ix.        } 
x.  
xi.        depth(document("partlist.xml")) 
xii.        
xiii. Find the maximum depth of the document named "partlist.xml." 
 

XML and Databases 

As was mentioned in the introduction, there is a dichotomy in how XML is used in 
industry. On one hand there is the document‐centric model of XML where XML is 
typically used as a means to creating semi‐structured documents with irregular content 
that are meant for human consumption. An example of document‐centric usage of XML 
is XHTML which is the XML based successor to HTML. 

 SAMPLE XHTML DOCUMENT 
 
      <html xmlns ="http://www.w3.org/1999/xhtml"> 
       <head> 
    <title>Sample Web Page</title> 
       </head> 
       <body> 
        <h1>My Sample Web Page</h1> 
        <p> All XHTML documents must be well‐formed and valid. </p> 
        <img src="http://www.example.com/sample.jpg" height ="50" width = "25"/> 
        <br /> 
        <br />         
       </body> 
      </html> 
 

The other primary usage of XML is in a data‐centric model. In a data‐centric model, XML 
is used as a storage or interchange format for data that is structured, appears in a 

64 
 
 
regular order and is most likely to be machine processed instead of read by a human. In 
a data‐centric model, the fact that the data is stored or transferred as XML is typically 
incidental since it could be stored or transferred in a number of other formats which 
may or may not be better suited for the task depending on the data and how it is used. 
An example of a data‐centric usage of XML is SOAP. SOAP is an XML based protocol used 
for exchanging information in a decentralized, distributed environment. A SOAP 
message consists of three parts: an envelope that defines a framework for describing 
what is in a message and how to process it, a set of encoding rules for expressing 
instances of application‐defined datatypes, and a convention for representing remote 
procedure calls and responses. 

 SAMPLE SOAP MESSAGE TAKEN FROM W3C SOAP RECOMMENDATION 
 
       <SOAP‐ENV:Envelope  xmlns:SOAP‐
ENV="http://schemas.xmlsoap.org/soap/envelope/" 
        SOAP‐ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"> 
        <SOAP‐ENV:Body> 
         <m:GetLastTradePrice xmlns:m="Some‐URI"> 
          <symbol>DIS</symbol> 
         </m:GetLastTradePrice> 
        </SOAP‐ENV:Body> 
       </SOAP‐ENV:Envelope> 
 
 

In both models where XML is used, it is sometimes necessary to store the XML in some 
sort of repository or database that allows for more sophisticated storage and retrieval of 
the data especially if the XML is to be accessed by multiple users. Below is a description 
of storage options based on what model of XML usage is required. 

7. Data‐centric model: In a data‐centric model where data is stored in a relational 
database or similar repository; one may want to extract data from a database as XML, store 
XML into a database or both. For situations where one only needs to extract XML from the 
database one may use a middleware application or component that retrieves data from the 
database and returns it as XML. Middleware components that transform relational data to XML 
and back vary widely in the functionality they provide and how they provide it.  
 
 
8. Document‐centric model: Content management systems are typically the 
tool of choice when considering storing, updating and retrieving various XML 
documents in a shared repository. A content management system typically 
consists of a repository that stores a variety of XML documents, an editor and an 
engine that provides one or more of the following features: 
ƒ version, revison and access control  
ƒ ability to reuse documents in different formats  
ƒ collaboration  

65 
 
 
ƒ web publishing facilities  
ƒ support for a variety of text editors (e.g. Microsoft Word, Adobe 
Framemaker, etc)  
ƒ indexing and search capabilities  
 
Content management systems have been primarily of benefit for workflow 
management in corporate environments where information sharing is vital and 
as a way to manage the creation of web content in a modular fashion allowing 
web developers and content creators to perform their tasks with less 
interdependence than exists in a traditional web authoring environment. 
Examples of XML based content management systems are SyCOMAX, Content@, 
Frontier, Entrepid, XDisect, and SiberSafe. 
9. Hybrid model: In situations where both documentric‐centric and data‐
centric models of XML usage will occur, the best data storage choice is usually a 
native XML database. What actually constitutes a native XML database has been 
a topic of some debate in various fora which has been compounded by the 
blurred lines that many see between XML‐enabled databases, XML query 
engines, XML servers and native XML databases. The most coherrent definition 
so far is one that was reached by consensus amongst members of the XML:DB 
mailing list which defines a native XML database as a database that has an XML 
document as its fundamental unit of (logical) storage and defines a (logical) 
model for an XML document, as opposed to the data in that document, and 
stores and retrieves documents according to that model. At a minimum, the 
model must include elements, attributes, PCDATA, and document order. 
Described below are two examples of native XML databases with the intent of 
showing the breadth of functionality and variety that can be expected in the 
native XML database arena. 
 
Querying the XML documents within the system is done using XPath and the 
documents can be indexed to improve query performance. 
 
dbXML is written in Java but supports access from other languages by exposing a 
CORBA API thus allowing interaction with any language that supports a CORBA 
binding. It also ships with a Java implementation of the XML:DB XML Database 
API which is designed to be a vendor neutral API for XML databases. A number of 
command line tools for managing documents and collections are also provided. 
 
dbXML is mostly still in development (version at time of writing was 1.0 beta 2) 
and does not currently support transactions or the use of schemas but these 
features are currently being developed for future versions.  
XML has evolved into a viable alternative for representing data. As more applications use XML, 
the big question becomes how to combine XML with relational databases. Let’s dive deeper 
into the issues involved in combining XML with databases and look at how all that data can be 
stored and queried. 
 
XML database types 
66 
 
 
 
There are two categories to consider when deciding which type of XML database fits a 
particular application: 
• Data‐centric: Products that actually store the data or content in non‐XML format 
• Document‐centric: Products that store complete XML documents in relational tables or 
on disk in file structures 
 
Data‐centric databases store data separate from the XML schema, usually just transforming the 
original content into relational tables. These products are referred to as XML‐enabled 
databases. If an XML document is needed, the data stored in relational tables can be queried 
and an XML document created. Most major relational databases (Sybase, Oracle, and SQL 
Server) fall into this category. 
 
Document‐centric databases store the entire XML document in a relational, text, or proprietary 
format. These are called native XML databases. A couple of popular native XML databases are 
the Xindice (zeen‐dee‐chay) open source product from Apache and eXist, which is also open 
source. 
 
Querying, XML style 
Support for XPath or XML queries is a primary feature in XML databases. The major relational 
database vendors provide XPath support, while native XML databases provide support for 
querying with XPath, usually via the XML:DB API. Finding developers who understand XPath, 
much less database administrators, is a problem. However, for a simply structured database or 
hierarchical database, or for XML documents, XPath is more efficient than SQL. Unfortunately, 
the necessary string and date functions to manipulate the results don’t exist in SQL (String and 
Date functions are used in the XSLT code). For more complete queries, XML Query is more like 
SQL but is less supported. 
 
For example, the SQL query below can’t be represented with XPath: 
SELECT left(name,3) from employees 
 
However, the following SQL: 
SELECT * FROM employees WHERE left(name,3) = 'hoo' 
 
can be queried with something like: 
//employees/name[starts‐with(last,'hoo')] 
 
and with this XML Query: 
for $t in document("employeeList.xml")//(employee)/name where contains($t/text(), "hoo") 
return $t } 
 
Bear in mind that XML:DB and XPath are more efficient at querying XML documents, not 
relational data structures. 
 
XML support in relational databases 

67 
 
 
 
XML‐enabled applications support creating information as XML, and reading XML is an 
important feature. Large vendors like Microsoft, Oracle, and IBM (and more) have succeeded in 
transforming relational data into XML and have XPath or XML Query implementations. Each 
platform also offers tools to compliment its database offerings. Programming is often required 
to maintain XML content, and SDKs (Software Development Kits) are available. 
 
Most systems (excluding XML databases) lack methods to directly import or read XML 
documents. You can program SQL Server 2000 with stored procedures to import XML content 
directly into one or more tables. DB2 and Oracle have similar functionality. 
 
XML‐centric applications, such as BizTalk Server and XML Spy, do a much better job at reading 
XML documents since they act as a bridge between the XML and database. However, these 
programs require a serious commitment and substantial investment. One reason that these 
applications import XML so easily is that they support XML Schemas and data type definitions 
(DTDs). As more mature XML applications are developed, translating XML data (reading and 
writing) based on a DTD or Schema will allow much more flexibility in how the data can be 
used, because the DTD or Schema is easily mapped to relational tables or the needed data 
model. 
 
Document content and Web pages 
Content delivered on Web sites is still basically stored in static HTML pages or relational 
databases, even though this type of "informational" content is probably best suited for XML. 
One of the more popular products that stores such content in XML is Cocoon from Apache. 
Enhydra is another Java/XML‐based application server, and the eXist and Xindice database 
products easily integrate with Cocoon. 
 
For catalogs, documents, and other data, XML delivers on the promise of an efficient data store 
and transport. More content is available with native XML databases or XML‐enabled relational 
databases. Web sites and online content will benefit most from a native XML database. For 
more information, check out the XML:DB Web site. 
 
Is XML a database?  
XML document is a collection of data. In other words it doesn’t make much difference between 
the other files that store data. A XML in a database format is a self describing, portable, and can 
describe data in tree or graph structure. XML is a sort of Database Management System 
(DBMS). 
XML provides storage, schemas, query languages, programming interfaces and so on .It lacks in 
triggers, queries, multi‐user access that a real database constitutes. The main advantage of XML 
is that the data is portable and it allows you to have nested entries. 
XML allows you to preserve physical document structure, supports document level transactions 
and execute queries in an XML query language. 
Mapping the XML document schema to the database schema does the transfer of data 
between XML documents and a database. Mappings between document schemas and database 
schemas are performed on attributes and text. There are 2 mappings that are generally used to 
map on XML document schema to the database schema: 
68 
 
 
I) TABLE BASED MAPPING 
ii) OBJECT RELATIONAL MAPPING 
Native XML databases are designed especially to store XML documents .It is always possible to 
store data in XML documents in a native XML database. This is done so, when your data is semi‐
structured. Although, this kind of data can be stored in object oriented and hierarchical 
databases, it is always better to store it in a native XML database. It enables us to retrieve data 
much faster than a relational database. One more reason is to store data in a native XML 
database is to exploit XML specification capabilities, such as executing XML queries. 
 
Advantages of web services built on XML based standards  
Web services built on XML based standards has a lot of benefits over the other web services 
that are based on RPC. The RPCs' are platform dependent but the web services built using the 
XML standards are platform and language independent. With this advantage you can use it for 
communication between any types of application that resides on any platform.  

The invocation information is passed to the service provider in the form an XML document and 
hence it is platform independent. The protocol used for such a transfer is the HTTP that is 
supported by all the browsers.  
Hence you can just pass on the information regarding the object that is to be executed through 
the browser itself using the HTTP. This is one of the major advantages of using the XML based 
web services as it can easily pass through the firewalls.  
 
 
 
 
 
 
 
 

Standard  Description 
 

and   

Comments 
 

XML 1.0 (4th  The Extensible Markup Language (XML) is a subset 
Ed.)   of SGML that is completely described in this 
document from the W3C. Its goal is to enable 
   
generic SGML to be served, received, and processed   

on the Web in the way that is now possible with 
HTML. XML has been designed for ease of 
implementation and for interoperability with both 
SGML and HTML. 
 

Namespaces  XML namespaces provide a simple method for 
 

in XML 1.0   

qualifying element and attribute names used in   

(2nd Ed.)  Extensible Markup Language (XML) documents by 
69 
 
 
associating them with namespaces identified by URI 
references. 
 

XML Infoset  XML Information Set (Infoset) provides a set of 
 

1.0 (2nd Ed.)  
 

definitions for use in other specifications that need   

to refer to the information in an XML document. 
 

XSLT 1.0   XSLT 1.0 is designed for use as part of XSL, which is 
a stylesheet language for XML. In addition to XSLT, 
XSL includes an XML vocabulary for specifying 
formatting. XSL specifies the styling of an XML 
   

document by using XSLT to describe how the   

document is transformed into another XML 
document that uses the formatting vocabulary.  
The rarely used elements xsl:strip‐space and 
xsl:preserve‐space are currently ignored. 
 

XSLT 2.0   XSLT 2.0 is the long‐awaited upgrade to XSLT 1.0 
and includes important new schema‐aware 
functions, grouping, aggregation, node‐set, "for" 
loops, and much more. For a detailed description of 
   

the new capabilities, please see this comparison.    

The rarely used elements xsl:strip‐space and 
xsl:preserve‐space are currently ignored. Also, the 
attribute input‐type‐annotations is not yet 
supported.  
 

XPath 1.0   XPath 1.0 is a language for addressing parts of an 
   

XML document, designed to be used by both XSLT   

and XPointer.  
 

XPath 2.0   XPath 2.0 is a superset of [XPath 1.0], with the 
added capability to support a richer set of data 
types, and to take advantage of the type 
   

information that becomes available when   

documents are validated using XML Schema. For a 
detailed description of the new capabilities, please 
see this comparison.  
 

XQuery 1.0   An extension of the XPath 2.0 specification, XQuery 
   

is a language for extracting information from XML   

documents and databases.  
 

XInclude 1.0  XInclude specifies a processing model and syntax 
 
(2nd Ed.)  

 
for general purpose inclusion. Inclusion is   

accomplished by merging a number of XML 
information sets into a single composite infoset. 
70 
 
 
Specification of the XML documents (infosets) to be 
merged and control over the merging process is 
expressed in XML‐friendly syntax (elements, 
attributes, URI references). 
 

XPointer 1.0   XML Pointer Language (XPointer) is the language to 
be used as the basis for a fragment identifier for any 
   
URI reference that locates a resource whose   

Internet media type is one of text/xml, 
application/xml, text/xml‐external‐parsed‐entity, or 
application/xml‐external‐parsed‐entity. 
 

XML Schema  XML Schema specifies the XML Schema definition 
1.0 (2nd Ed.)   language, which offers facilities for describing the 
structure and constraining the contents of XML 1.0 
documents, including those which exploit the XML 
   

Namespace facility. The schema language, which is   

itself represented in XML 1.0 and uses namespaces, 
substantially reconstructs and considerably extends 
the capabilities found in XML 1.0 document type 
definitions (DTDs). 
 

SOAP 1.2   SOAP is a lightweight protocol for exchange of 
information in a decentralized, distributed 
environment. It is an XML based protocol that 
consists of three parts: an envelope that defines a 
framework for describing what is in a message and 
how to process it, a set of encoding rules for 
   
expressing instances of application‐defined   

datatypes, and a convention for representing 
remote procedure calls and responses. SOAP can 
potentially be used in combination with a variety of 
other protocols; however, the only bindings defined 
in this document describe how to use SOAP in 
combination with HTTP and HTTP Extension 
Framework. 
 

WSDL 1.1   WSDL is an XML format for describing network 
services as a set of endpoints operating on 
messages containing either document‐oriented or 
procedure‐oriented information. The operations 
   

and messages are described abstractly, and then   

bound to a concrete network protocol and message 
format to define an endpoint. Related concrete 
endpoints are combined into abstract endpoints 
(services). WSDL is extensible to allow description 

71 
 
 
of endpoints and their messages regardless of what 
message formats or network protocols are used to 
communicate, however, the only bindings described 
in this document describe how to use WSDL in 
conjunction with SOAP 1.1, HTTP GET/POST, and 
MIME. 
 

RDF   Resource Description Framework (RDF) is a family 
of W3C specifications originally designed as a 
   

metadata data model, that has come to be used as   

a general method of modeling information through 
a variety of syntax formats. 
 

OWL   The OWL Web Ontology Language is designed for 
use by applications that need to process the 
content of information instead of just presenting 
information to humans. OWL facilitates greater 
   

machine interpretability of Web content than that   

supported by XML, RDF, and RDF Schema (RDF‐S) by 
providing additional vocabulary along with a formal 
semantics. OWL has three increasingly‐expressive 
sublanguages: OWL Lite, OWL DL, and OWL Full. 
 

XML Catalogs   In order to make optimal use of the information 
about an XML external resource, there needs to be 
some interoperable way to map the information in 
an XML external identifier into a URI reference for 
the desired resource. 
This OASIS XML Catalog Standard defines an entity 
   

catalog that handles two simple cases:   

• Mapping an external entity's public 
identifier and/or system identifier to a URI 
reference. 
• Mapping the URI reference of a resource (a 
namespace name, stylesheet, image, etc.) to 
another URI reference. 
 

Unicode 4.1.0   The Unicode Standard, Version 4.1.0, defined by: 
   
The Unicode Standard, Version 4.0 (Boston, MA,   

Addison‐Wesley, 2003. ISBN 0‐321‐18578‐1), as 
amended by Unicode 4.0.1 and Unicode 4.1.0. 
 

UML 2.2   UML is a graphical language for organizing, 
   
analyzing, and planning object‐oriented or   

component‐based software projects. The UML 2.2 
specification defines thirteen major different 

72 
 
 
diagram types and over one thousand graphical and 
textual language elements, as well as additional 
extension mechanisms. 
 

XMI 2.1   XMI is a model driven XML Integration framework 
for defining, interchanging, manipulating and 
integrating XML data and objects. XMI‐based 
   
standards are in use for integrating tools,   

repositories, applications and data warehouses. XMI 
provides rules by which a schema can be generated 
for any valid XMI‐transmissible MOF‐based 
metamodel. 
 

BPMN 1.0   The Business Process Modeling Notation (BPMN) is 
a graphical notation that depicts the steps in a 
business process. BPMN depicts the end to end flow 
   
of a business process. The notation has been   

specifically designed to coordinate the sequence of 
processes and the messages that flow between 
different process participants in a related set of 
activities. 
 

CSS 2.1   CSS 2.1 is a style sheet language that allows authors 
and users to attach style (e.g., fonts and spacing) to 
structured documents (e.g., HTML documents and 
   

XML applications). By separating the presentation   

style of documents from the content of documents, 
CSS 2.1 simplifies Web authoring and site 
maintenance. 
 

HTML 4.01   HTML 4 supports more multimedia options, 
scripting languages, style sheets, better printing 
facilities, and documents that are more accessible 
   

to users with disabilities. HTML 4 also takes great   

strides towards the internationalization of 
documents, with the goal of making the Web truly 
World Wide. 
 

JavaScript   JavaScript is a scripting language that is often used 
for client‐side Web development to write functions 
that are embedded or included from HTML pages 
   
for dynamic presentation features such as pop‐up   

windows, form validation, and mouse‐over effects. 
JavaScript is a superset of the ECMA‐262 Edition 3 
(ECMAScript) standard scripting language, with only 
mild differences from the published standard. 
 

73 
 
 
EDIFACT D  EDIFACT is a set of United Nations rules for 
1993A ‐ D  Electronic Data Interchange for Administration, 
2007B   Commerce and Transport. They comprise a set of 
   
internationally agreed standards, directories and   

guidelines for the electronic interchange of 
structured data, and in particular that related to 
trade in goods and services between independent, 
computerized information systems. 
 

X12 3040 ‐  ASC X12 brings together business and industry 
5030   professionals in a cross‐industry forum to develop 
and support electronic data exchange standards 
   

and related documents for the national and   

international marketplace to enhance business 
processes, reduce costs and expand organizational 
reach.  
 

WebDAV   WebDAV stands for "Web‐based Distributed 
Authoring and Versioning". It is a set of extensions 
   

to the HTTP protocol which allows users to   

collaboratively edit and manage files on remote 
web servers. 
 

SQL   ISO/IEC 9075 defines the SQL database language. 
The scope of SQL is the definition of data structure 
   
and the operations on data stored in that structure.   

ISO/IEC 9075‐1, ‐2 and ‐11 encompass the minimum 
requirements of the language. Other parts define 
extensions. 
 

 
Output formats: 
 
Standard  Description and Comments 
     

RTF 1.9   The Rich Text Format (RTF) Specification provides a format for text and 
graphics interchange that can be used with different output devices, 
   

operating environments, and operating systems. Version 1.9.1 of the   

specification contains the latest updates introduced by Microsoft Office 
Word 2007. 
 

PDF 1.7   PDF is now a formal open standard known as ISO 32000. Maintained by the 
International Organization for Standardization, ISO 32000 will continue to be 
   

developed with the objective of protecting the integrity and longevity of PDF,   

providing an open standard for the more than one billion PDF files in 
existence today. 
 

74 
 
 
XSL:FO
  XSL:FO, is a markup language for XML document formatting which is most 
   
often used to generate PDFs. XSL:FO is part of XSL, a set of W3C technologies 
designed for the transformation and formatting of XML data. The other parts   
of XSL are XSLT and XPath. 
 

 
 
 
 
 
 
DTD –DOCUMENT TYPE DEFINITION  
 
The purpose of a DTD (Document Type Definition) is to define the legal building blocks of an 
XML document. 
A DTD defines the document structure with a list of legal elements and attributes. 

DTD Newspaper Example 
<!DOCTYPE NEWSPAPER [ 
 
<!ELEMENT NEWSPAPER (ARTICLE+)> 
<!ELEMENT ARTICLE (HEADLINE,BYLINE,LEAD,BODY,NOTES)> 
<!ELEMENT HEADLINE (#PCDATA)> 
<!ELEMENT BYLINE (#PCDATA)> 
<!ELEMENT LEAD (#PCDATA)> 
<!ELEMENT BODY (#PCDATA)> 
<!ELEMENT NOTES (#PCDATA)>  
<!ATTLIST ARTICLE AUTHOR CDATA #REQUIRED> 
<!ATTLIST ARTICLE EDITOR CDATA #IMPLIED> 
<!ATTLIST ARTICLE DATE CDATA #IMPLIED> 
<!ATTLIST ARTICLE EDITION CDATA #IMPLIED> 
 
]>  

Introduction to DTD 
 
A Document Type Definition (DTD) defines the legal building blocks of an XML document. It 
defines the document structure with a list of legal elements and attributes. 
A DTD can be declared inline inside an XML document, or as an external reference. 
 
Internal DTD Declaration 
If the DTD is declared inside the XML file, it should be wrapped in a DOCTYPE definition with the 
following syntax: 
<!DOCTYPE root‐element [element‐declarations]> 
75 
 
 
Example XML document with an internal DTD: 
<?xml version="1.0"?> 
<!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> 
<heading>Reminder</heading> 
<body>Don't forget me this weekend</body> 
</note> 
Open the XML file above in your browser (select "view source" or "view page source" to view 
the DTD) 
The DTD above is interpreted like this: 
• !DOCTYPE note defines that the root element of this document is note 
• !ELEMENT note defines that the note element contains four elements: 
"to,from,heading,body" 
• !ELEMENT to defines the to element  to be of type "#PCDATA" 
• !ELEMENT from defines the from element to be of type "#PCDATA" 
• !ELEMENT heading defines the heading element to be of type "#PCDATA" 
• !ELEMENT body defines the body element to be of type "#PCDATA" 
 
External DTD Declaration 
If the DTD is declared in an external file, it should be wrapped in a DOCTYPE definition with the 
following syntax:  <!DOCTYPE root‐element SYSTEM "filename"> 
This is the same XML document as above, but with an external DTD (Open it, and select view 
source): 
<?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> 
And this is the file "note.dtd" which contains the DTD: 
<!ELEMENT note (to,from,heading,body)> 
<!ELEMENT to (#PCDATA)> 
<!ELEMENT from (#PCDATA)> 
<!ELEMENT heading (#PCDATA)> 
<!ELEMENT body (#PCDATA)> 
 
76 
 
 
Why Use a DTD? 
With a DTD, each of your XML files can carry a description of its own format. 
With a DTD, independent groups of people can agree to use a standard DTD for interchanging 
data. 
Your application can use a standard DTD to verify that the data you receive from the outside 
world is valid.You can also use a DTD to verify your own data. 

DTD ‐ XML Building Blocks 
 
The main building blocks of both XML and HTML documents are elements. 
 
The Building Blocks of XML Documents 
Seen from a DTD point of view, all XML documents (and HTML documents) are made up by the 
following building blocks: 
• Elements 
• Attributes 
• Entities 
• PCDATA 
• CDATA 
 
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". 
Examples: 
<body>some text</body> 
<message>some text</message> 
 
Attributes 
Attributes provide extra information about elements. 
Attributes are always placed inside the opening tag of an element. Attributes always come in 
name/value pairs. The following "img" element has 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 " /". 
 
Entities 
Some characters have a special meaning in XML, like the less than sign (<) that defines the start 
of an XML tag. 
Most of you know the HTML entity: "&nbsp;". This "no‐breaking‐space" entity is used in HTML 
to insert an extra space in a document. Entities are expanded when a document is parsed by an 
XML parser. 
The following entities are predefined in XML: 
Entity References  Character 

77 
 
 
&lt;  < 
&gt;  > 
&amp;  & 
&quot;  " 
&apos;  ' 
   
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. The text will be examined by the parser for 
entities and markup. 
Tags inside the text will be treated as markup and entities will be expanded. 
However, parsed character data should not contain any &, <, or > characters; these need to be 
represented by the &amp; &lt; and &gt; entities, respectively. 
 
CDATA 
CDATA 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. 

DTD ‐ Elements 
 
In a DTD, elements are declared with an ELEMENT declaration. 
 
Declaring Elements 
In a DTD, XML elements are declared with an element declaration with the following syntax: 
<!ELEMENT element‐name category> 
or 
<!ELEMENT element‐name (element‐content)> 
 
Empty Elements 
Empty elements are declared with the category keyword EMPTY: 
<!ELEMENT element‐name EMPTY> 
 
Example: 
 
<!ELEMENT br EMPTY> 
 
XML example: 
 
<br /> 
 
Elements with Parsed Character Data 
Elements with only parsed character data are declared with #PCDATA inside parentheses: 
78 
 
 
<!ELEMENT element‐name (#PCDATA)> 
 
Example: 
 
<!ELEMENT from (#PCDATA)> 
 
Elements with any Contents 
Elements declared with the category keyword ANY, can contain any combination of parsable 
data: 
<!ELEMENT element‐name ANY> 
Example: 
<!ELEMENT note ANY> 
 
Elements with Children (sequences) 
Elements with one or more children are declared with the name of the children elements inside 
parentheses: 
<!ELEMENT element‐name (child1)> 
or 
<!ELEMENT element‐name (child1,child2,...)> 
 
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" element is:  
<!ELEMENT note (to,from,heading,body)> 
<!ELEMENT to (#PCDATA)> 
<!ELEMENT from (#PCDATA)> 
<!ELEMENT heading (#PCDATA)> 
<!ELEMENT body (#PCDATA)> 
 
Declaring Only One Occurrence of an Element 
<!ELEMENT element‐name (child‐name)> 
 
Example: 
 
<!ELEMENT note (message)> 
The example above declares that the child element "message" must occur once, and only once 
inside the "note" element. 
 
Declaring Minimum One Occurrence of an Element 
<!ELEMENT element‐name (child‐name+)> 
 
Example: 
 
79 
 
 
<!ELEMENT note (message+)> 
The + sign in the example above declares that the child element "message" must occur one or 
more times inside the "note" element. 
 
Declaring Zero or More Occurrences of an Element 
<!ELEMENT element‐name (child‐name*)> 
 
Example: 
 
<!ELEMENT note (message*)> 
The * sign in the example above declares that the child element "message" can occur zero or 
more times inside the "note" element. 
 
Declaring Zero or One Occurrences of an Element  
<!ELEMENT element‐name (child‐name?)> 
 
Example: 
 
<!ELEMENT note (message?)> 
The ? sign in the example above declares that the child element "message" can occur zero or 
one time inside the "note" element. 
 
Declaring either/or Content 
Example: 
 
<!ELEMENT note (to,from,header,(message|body))> 
The example above declares that the "note" element must contain a "to" element, a "from" 
element, a "header" element, and either a "message" or a "body" element. 
 
Declaring Mixed Content 
Example: 
 
<!ELEMENT note (#PCDATA|to|from|header|message)*> 
The example above declares that the "note" element can contain zero or more occurrences of 
parsed character data, "to", "from", "header", or "message" elements. 

DTD ‐ Attributes 

In a DTD, attributes are declared with an ATTLIST declaration. 

 
Declaring Attributes 

An attribute declaration has the following syntax: 

80 
 
 
<!ATTLIST element‐name attribute‐name attribute‐type default‐value> 
 
DTD example: 
 
<!ATTLIST payment type CDATA "check"> 
 
XML example: 
 
<payment type="check" />  

The attribute‐type can be one of the following: 

Type  Description 
CDATA  The value is character data 
(en1|en2|..)  The value must be one from an enumerated list 
ID  The value is a 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 a predefined xml value 

The default‐value can be one of the following: 

Value  Explanation 
value  The default value of the attribute 
#REQUIRED  The attribute is required 
#IMPLIED  The attribute is not required 
#FIXED value  The attribute value is fixed 
 

A Default Attribute Value 
DTD: 
<!ELEMENT square EMPTY> 
<!ATTLIST square width CDATA "0"> 
 
Valid XML: 
<square width="100" /> 

81 
 
 
In the example above, the "square" element is defined to be an empty element with a "width" 
attribute of  type CDATA. If no width is specified, it has a default value of 0.
 

#REQUIRED 

Syntax 
<!ATTLIST element‐name attribute‐name attribute‐type #REQUIRED> 

Example 
DTD: 
<!ATTLIST person number CDATA #REQUIRED> 
 
Valid XML: 
<person number="5677" /> 
 
Invalid XML: 
<person /> 

Use the #REQUIRED keyword if you don't have an option for a default value, but still want to 
force the attribute to be present. 

#IMPLIED 

Syntax 
<!ATTLIST element‐name attribute‐name attribute‐type #IMPLIED> 

Example 
DTD: 
<!ATTLIST contact fax CDATA #IMPLIED> 
 
Valid XML: 
<contact fax="555‐667788" /> 
 
Valid XML: 
<contact /> 

Use the #IMPLIED keyword if you don't want to force the author to include an attribute, and 
you don't have an option for a default value.
 

#FIXED 

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

Example 
DTD: 
82 
 
 
<!ATTLIST sender company CDATA #FIXED "Microsoft"> 
 
Valid XML: 
<sender company="Microsoft" /> 
 
Invalid XML: 
<sender company="W3Schools" /> 

Use the #FIXED keyword 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 (en1|en2|..) default‐value> 

Example 
DTD: 
<!ATTLIST payment type (check|cash) "cash"> 
 
XML example: 
<payment type="check" /> 
or 
<payment type="cash" /> 

Use enumerated attribute values when you want the attribute value to be one of a fixed set of 
legal values. 

XML Elements vs. Attributes 
 
In XML, there are no rules about when to use attributes, and when to use child elements. 
 
Use of Elements vs. Attributes 
Data can be stored in child elements or in attributes. 
Take a look at these examples: 
<person sex="female"> 
  <firstname>Anna</firstname> 
  <lastname>Smith</lastname> 
</person> 
 
<person> 
  <sex>female</sex> 
  <firstname>Anna</firstname> 
  <lastname>Smith</lastname> 
</person> 
83 
 
 
In the first example sex is an attribute. In the last, sex is a child element. Both examples provide 
the same information. 
There are no rules about when to use attributes, and when to use child elements. My 
experience is that attributes are handy in HTML, but in XML you should try to avoid them. Use 
child elements if the information feels like data. 
 
My Favorite Way 
I like to store data in child elements. 
The following three XML documents contain exactly the same information: 
A date attribute is used in the first example: 
<note date="12/11/2002"> 
  <to>Tove</to> 
  <from>Jani</from> 
  <heading>Reminder</heading> 
  <body>Don't forget me this weekend!</body> 
</note>  
A date element is used in the second example: 
<note> 
  <date>12/11/2002</date> 
  <to>Tove</to> 
  <from>Jani</from> 
  <heading>Reminder</heading> 
  <body>Don't forget me this weekend!</body> 
</note>  
An expanded date element is used in the third: (THIS IS MY FAVORITE): 
<note> 
  <date> 
    <day>12</day> 
    <month>11</month> 
    <year>2002</year> 
  </date> 
  <to>Tove</to> 
  <from>Jani</from> 
  <heading>Reminder</heading> 
  <body>Don't forget me this weekend!</body> 
</note>  
 
 
Avoid using attributes? 
Should you avoid using attributes? 
Some of the problems with attributes are: 
• attributes cannot contain multiple values (child elements can) 
• attributes are not easily expandable (for future changes) 
• attributes cannot describe structures (child elements can) 
• attributes are more difficult to manipulate by program code 
• attribute values are not easy to test against a DTD 
84 
 
 
If you use attributes as containers for data, you end up with documents that are difficult to read 
and maintain. Try to use elements to describe data. Use attributes only to provide information 
that is not relevant to the data. 
Don't end up like this (this is not how XML should be used): 
<note day="12" month="11" year="2002" 
to="Tove" from="Jani" heading="Reminder" 
body="Don't forget me this weekend!"> 
</note>  
 
 
An Exception to my Attribute Rule 
Rules always have exceptions. 
My rule about attributes has one exception: 
Sometimes I assign ID references to elements. These ID references can be used to access XML 
elements in much the same way as the NAME or ID attributes in HTML. This example 
demonstrates this: 
<messages> 
<note id="p501"> 
  <to>Tove</to> 
  <from>Jani</from> 
  <heading>Reminder</heading> 
  <body>Don't forget me this weekend!</body> 
</note> 
 
<note id="p502"> 
  <to>Jani</to> 
  <from>Tove</from> 
  <heading>Re: Reminder</heading> 
  <body>I will not!</body> 
</note> 
</messages>  
The ID in these examples is just a counter, or a unique identifier, to identify the different notes 
in the XML file, and not a part of the note data. 
What I am trying to say here is that metadata (data about data) should be stored as attributes, 
and that data itself should be stored as elements. 

DTD ‐ Entities 

Entities are variables used to define shortcuts to standard text or special characters. 
• Entity references are references to entities 
• Entities can be declared internal or external 

85 
 
 
An Internal Entity Declaration 

Syntax 
<!ENTITY entity‐name "entity‐value"> 
 
DTD Example: 
 
<!ENTITY writer "Donald Duck."> 
<!ENTITY copyright "Copyright W3Schools."> 
 
XML example:                          <author>&writer;&copyright;</author> 

Note: An entity has three parts: an ampersand (&), an entity name, and a semicolon (;).
 

An External Entity Declaration 

Syntax 
<!ENTITY entity‐name SYSTEM "URI/URL"> 

Example 
DTD Example: 
 
<!ENTITY writer SYSTEM "http://www.w3schools.com/entities.dtd"> 
<!ENTITY copyright SYSTEM "http://www.w3schools.com/entities.dtd"> 
 
XML example: 
<author>&writer;&copyright;</author> 

DTD Validation 

With Internet Explorer 5+ you can validate your XML against a DTD. 
 
Validating With the XML Parser 
If you try to open an XML document, the XML Parser might generate an error. By accessing the 
parseError object, you can retrieve the error code, the error text, or even the line that caused 
the error. 
Note: The load( ) method is used for files, while the loadXML( ) method is used for strings. 
Example 
var xmlDoc = new ActiveXObject("Microsoft.XMLDOM"); 
xmlDoc.async="false"; 
xmlDoc.validateOnParse="true"; 
xmlDoc.load("note_dtd_error.xml"); 
document.write("<br />Error Code: "); 
document.write(xmlDoc.parseError.errorCode); 
document.write("<br />Error Reason: "); 

86 
 
 
document.write(xmlDoc.parseError.reason); 
document.write("<br />Error Line: "); 
document.write(xmlDoc.parseError.line); 
 

 
Turn Validation Off 
Validation can be turned off by setting the XML parser's validateOnParse="false". 
Example 
var xmlDoc = new ActiveXObject("Microsoft.XMLDOM"); 
xmlDoc.async="false"; 
xmlDoc.validateOnParse="false"; 
xmlDoc.load("note_dtd_error.xml"); 
 
document.write("<br />Error Code: "); 
document.write(xmlDoc.parseError.errorCode); 
document.write("<br />Error Reason: "); 
document.write(xmlDoc.parseError.reason); 
document.write("<br />Error Line: "); 
document.write(xmlDoc.parseError.line); 
 

DTD ‐ Examples from the internet 
 
TV Schedule DTD 
By David Moisan. Copied from http://www.davidmoisan.org/ 
<!DOCTYPE TVSCHEDULE [ 
 
<!ELEMENT TVSCHEDULE (CHANNEL+)> 
<!ELEMENT CHANNEL (BANNER,DAY+)> 
<!ELEMENT BANNER (#PCDATA)> 
<!ELEMENT DAY (DATE,(HOLIDAY|PROGRAMSLOT+)+)> 
<!ELEMENT HOLIDAY (#PCDATA)> 
<!ELEMENT DATE (#PCDATA)> 
<!ELEMENT PROGRAMSLOT (TIME,TITLE,DESCRIPTION?)> 
<!ELEMENT TIME (#PCDATA)> 
<!ELEMENT TITLE (#PCDATA)>  
<!ELEMENT DESCRIPTION (#PCDATA)> 
<!ATTLIST TVSCHEDULE NAME CDATA #REQUIRED> 
<!ATTLIST CHANNEL CHAN CDATA #REQUIRED> 
<!ATTLIST PROGRAMSLOT VTR CDATA #IMPLIED> 
<!ATTLIST TITLE RATING CDATA #IMPLIED> 
<!ATTLIST TITLE LANGUAGE CDATA #IMPLIED> 
]> 
 
 
Newspaper Article DTD 
Copied from http://www.vervet.com/ 

87 
 
 
<!DOCTYPE NEWSPAPER [ 
<!ELEMENT NEWSPAPER (ARTICLE+)> 
<!ELEMENT ARTICLE (HEADLINE,BYLINE,LEAD,BODY,NOTES)> 
<!ELEMENT HEADLINE (#PCDATA)> 
<!ELEMENT BYLINE (#PCDATA)> 
<!ELEMENT LEAD (#PCDATA)> 
<!ELEMENT BODY (#PCDATA)> 
<!ELEMENT NOTES (#PCDATA)> 
<!ATTLIST ARTICLE AUTHOR CDATA #REQUIRED> 
<!ATTLIST ARTICLE EDITOR CDATA #IMPLIED> 
<!ATTLIST ARTICLE DATE CDATA #IMPLIED> 
<!ATTLIST ARTICLE EDITION CDATA #IMPLIED> 
<!ENTITY NEWSPAPER "Vervet Logic Times"> 
<!ENTITY PUBLISHER "Vervet Logic Press"> 
<!ENTITY COPYRIGHT "Copyright 1998 Vervet Logic Press"> 
]> 
 
 
Product Catalog DTD 
Copied from http://www.vervet.com/ 
<!DOCTYPE CATALOG [ 
<!ENTITY AUTHOR "John Doe"> 
<!ENTITY COMPANY "JD Power Tools, Inc."> 
<!ENTITY EMAIL "jd@jd‐tools.com"> 
<!ELEMENT CATALOG (PRODUCT+)> 
<!ELEMENT PRODUCT 
(SPECIFICATIONS+,OPTIONS?,PRICE+,NOTES?)> 
<!ATTLIST PRODUCT 
NAME CDATA #IMPLIED 
CATEGORY (HandTool|Table|Shop‐Professional) "HandTool" 
PARTNUM CDATA #IMPLIED 
PLANT (Pittsburgh|Milwaukee|Chicago) "Chicago" 
INVENTORY (InStock|Backordered|Discontinued) "InStock"> 
<!ELEMENT SPECIFICATIONS (#PCDATA)> 
<!ATTLIST SPECIFICATIONS 
WEIGHT CDATA #IMPLIED 
POWER CDATA #IMPLIED> 
<!ELEMENT OPTIONS (#PCDATA)> 
<!ATTLIST OPTIONS 
FINISH (Metal|Polished|Matte) "Matte" 
ADAPTER (Included|Optional|NotApplicable) "Included" 
CASE (HardShell|Soft|NotApplicable) "HardShell"> 
<!ELEMENT PRICE (#PCDATA)> 
<!ATTLIST PRICE 
MSRP CDATA #IMPLIED 
WHOLESALE CDATA #IMPLIED 
88 
 
 
STREET CDATA #IMPLIED 
SHIPPING CDATA #IMPLIED> 
<!ELEMENT NOTES (#PCDATA)> 
]> 
 
DTD Summary 
This tutorial has taught you how to describe the structure of an XML document. 
You have learned how to use a DTD to define the legal elements of an XML document, and how 
a DTD can be declared inside your XML document, or as an external reference. 
You have learned how to declare the legal elements, attributes, entities, and CDATA sections 
for XML documents. 
You have also seen how to validate an XML document against a DTD. 
 
Now You Know DTD, What's Next? 
The next step is to learn about XML Schema. 
XML Schema is used to define the legal elements of an XML document, just like a DTD. We think 
that very soon XML Schemas will be used in most Web applications as a replacement for DTDs. 
XML Schema is an XML‐based alternative to DTD. 
Unlike DTD, XML Schemas has support for data types and namespaces. 

Limitations / Problems with DTD 
Top 15 reasons for avoiding DTD:  
1. not itself using XML syntax (the SGML heritage can be very unintuitive + if using XML, 
DTDs could potentially themselves be syntax checked with a "meta DTD")  
2. mixed into the XML 1.0 spec (would be much less confusing if specified separately + 
even non‐validating processors must look at the DTD) 
3. no constraints on character data (if character data is allowed, any character data is 
allowed) 
4. too simple attribute value models (enumerations are clearly insufficient) 
5. cannot mix character data and regexp content models (and the content models are 
generally hard to use for complex requirements) 
6. no support for Namespaces (of course, XML 1.0 was defined before Namespaces) 
7. very limited support for modularity and reuse (the entity mechanism is too low‐level) 
8. no support for schema evolution, extension, or inheritance of declarations (difficult to 
write, maintain, and read large DTDs, and to define families of related schemas) 
9. limited white‐space control (xml:space is rarely used) 
10. no embedded, structured self‐documentation (<!‐‐ comments ‐‐> are not enough) 
11. content and attribute declarations cannot depend on attributes or element context 
(many XML languages use that, but their DTDs have to "allow too much") 
12. too simple ID attribute mechanism (no points‐to requirements, uniqueness scope, etc.) 
13. only defaults for attributes, not for elements (but that would often be convenient) 
14. cannot specify "any element" or "any attribute" (useful for partial specifications and 
during schema development) 
15. defaults cannot be specified separate from the declarations (would be convenient to 
have defaults in separate modules) 

89 
 
 
 
 
 
 
XML Schema 

An XML Schema describes the structure of an XML document. 
In this tutorial you will learn how to create XML Schemas, why XML Schemas are more powerful 
than DTDs, and how to use XML Schema in your application. 

XML Schema Example 
<?xml version="1.0"?> 
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
 
<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> 
 

Introduction to XML Schema 

XML Schema is an XML‐based alternative to DTD. 
An XML schema describes the structure of an XML document. 
The XML Schema language is also referred to as XML Schema Definition (XSD). 

 
What You Should Already Know 

Before you continue you should have a basic understanding of the following: 

• HTML / XHTML 
• XML and XML Namespaces 
• A basic understanding of DTD 
 

90 
 
 
What is an XML Schema? 

The purpose of an XML Schema is to define the legal building blocks of an XML document, just 
like a DTD. 
An XML Schema: 

• defines elements that can appear in a document 
• defines attributes that can appear in a document 
• defines which elements are child elements 
• defines the order of child elements 
• defines the number of child elements 
• defines whether an element is empty or can include text 
• defines data types for elements and attributes 
• defines default and fixed values for elements and attributes 
 
XML Schemas are the Successors of DTDs 

We think that very soon XML Schemas will be used in most Web applications as a replacement 
for DTDs. Here are some reasons: 

• XML Schemas are extensible to future additions 
• XML Schemas are richer and more powerful than DTDs 
• XML Schemas are written in XML 
• XML Schemas support data types 
• XML Schemas support namespaces 
 
XML Schema is a W3C Recommendation 

XML Schema became a W3C Recommendation 02. May 2001. 

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) 
91 
 
 
• 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 
92 
 
 
• 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": 

<?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 note (to, from, heading, body)> 
<!ELEMENT to (#PCDATA)> 
<!ELEMENT from (#PCDATA)> 
<!ELEMENT heading (#PCDATA)> 
<!ELEMENT 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". 

93 
 
 
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" 
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: 

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

94 
 
 
 
A Reference to an XML Schema 

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> 

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"> 
... 
... 

95 
 
 
</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: 

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: 
96 
 
 
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" 

you can use the schemaLocation attribute. This attribute has two values. 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. 
However, the "only text" restriction is quite misleading. 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. 
You can also add restrictions (facets) to a data type in order to limit its content, or you can 
require the data to match a specific pattern. 

 
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 

97 
 
 
• 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. 

98 
 
 
 
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"/> 
 
 

99 
 
 
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. 
With XML Schemas, you can also add your own restrictions to your XML elements and 
attributes. These restrictions are called facets. You can read more about facets in the next 
chapter. 

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. 

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

The example above could also have been written like this: 

<xs:element name="car" type="carType"/> 
 
<xs:simpleType name="carType"> 
  <xs:restriction base="xs:string"> 
    <xs:enumeration value="Audi"/> 
    <xs:enumeration value="Golf"/> 
    <xs:enumeration value="BMW"/> 
  </xs:restriction> 
</xs:simpleType> 

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> 

The next example defines an element called "initials" with a restriction. The only acceptable 
value is THREE of the UPPERCASE letters from a to z: 
101 
 
 
<xs:element name="initials"> 
  <xs:simpleType> 
    <xs:restriction base="xs:string"> 
      <xs:pattern value="[A‐Z][A‐Z][A‐Z]"/> 
    </xs:restriction> 
  </xs:simpleType> 
</xs:element> 

The next example also defines an element called "initials" with a restriction. The only 
acceptable value is THREE of the LOWERCASE OR UPPERCASE letters from a to z: 

<xs:element name="initials"> 
  <xs:simpleType> 
    <xs:restriction base="xs:string"> 
      <xs:pattern value="[a‐zA‐Z][a‐zA‐Z][a‐zA‐Z]"/> 
    </xs:restriction> 
  </xs:simpleType> 
</xs:element> 

The next example defines an element called "choice" with a restriction. The only acceptable 
value is ONE of the following letters: x, y, OR z: 

<xs:element name="choice"> 
  <xs:simpleType> 
    <xs:restriction base="xs:string"> 
      <xs:pattern value="[xyz]"/> 
    </xs:restriction> 
  </xs:simpleType> 
</xs:element> 

The next example defines an element called "prodid" with a restriction. The only acceptable 
value is FIVE digits in a sequence, and each digit must be in a range from 0 to 9: 

<xs:element name="prodid"> 
  <xs:simpleType> 
    <xs:restriction base="xs:integer"> 
      <xs:pattern value="[0‐9][0‐9][0‐9][0‐9][0‐9]"/> 
    </xs:restriction> 
  </xs:simpleType> 
</xs:element> 
 
 
Other Restrictions on a Series of Values 

The example below defines an element called "letter" with a restriction. The acceptable value is 
zero or more occurrences of lowercase letters from a to z: 
102 
 
 
<xs:element name="letter"> 
  <xs:simpleType> 
    <xs:restriction base="xs:string"> 
      <xs:pattern value="([a‐z])*"/> 
    </xs:restriction> 
  </xs:simpleType> 
</xs:element> 

The next example also defines an element called "letter" with a restriction. The acceptable 
value is one or more pairs of letters, each pair consisting of a lower case letter followed by an 
upper case letter. For example, "sToP" will be validated by this pattern, but not "Stop" or 
"STOP" or "stop": 

<xs:element name="letter"> 
  <xs:simpleType> 
    <xs:restriction base="xs:string"> 
      <xs:pattern value="([a‐z][A‐Z])+"/> 
    </xs:restriction> 
  </xs:simpleType> 
</xs:element> 

The next example defines an element called "gender" with a restriction. The only acceptable 
value is male OR female: 

<xs:element name="gender"> 
  <xs:simpleType> 
    <xs:restriction base="xs:string"> 
      <xs:pattern value="male|female"/> 
    </xs:restriction> 
  </xs:simpleType> 
</xs:element> 

The next example defines an element called "password" with a restriction. There must be 
exactly eight characters in a row and those characters must be lowercase or uppercase letters 
from a to z, or a number from 0 to 9: 

<xs:element name="password"> 
  <xs:simpleType> 
    <xs:restriction base="xs:string"> 
      <xs:pattern value="[a‐zA‐Z0‐9]{8}"/> 
    </xs:restriction> 
  </xs:simpleType> 
</xs:element> 
 
 

103 
 
 
Restrictions on Whitespace Characters 

To specify how whitespace characters should be handled, we would use the whiteSpace 
constraint. 
This example defines an element called "address" with a restriction. The whiteSpace constraint 
is set to "preserve", which means that the XML processor WILL NOT remove any white space 
characters: 

<xs:element name="address"> 
  <xs:simpleType> 
    <xs:restriction base="xs:string"> 
      <xs:whiteSpace value="preserve"/> 
    </xs:restriction> 
  </xs:simpleType> 
</xs:element> 

This example also defines an element called "address" with a restriction. The whiteSpace 
constraint is set to "replace", which means that the XML processor WILL REPLACE all white 
space characters (line feeds, tabs, spaces, and carriage returns) with spaces: 

<xs:element name="address"> 
  <xs:simpleType> 
    <xs:restriction base="xs:string"> 
      <xs:whiteSpace value="replace"/> 
    </xs:restriction> 
  </xs:simpleType> 
</xs:element> 

This example also defines an element called "address" with a restriction. The whiteSpace 
constraint is set to "collapse", which means that the XML processor WILL REMOVE all white 
space characters (line feeds, tabs, spaces, carriage returns are replaced with spaces, leading 
and trailing spaces are removed, and multiple spaces are reduced to a single space): 

<xs:element name="address"> 
  <xs:simpleType> 
    <xs:restriction base="xs:string"> 
      <xs:whiteSpace value="collapse"/> 
    </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. 
104 
 
 
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> 
  </xs:simpleType> 
</xs:element> 
 
 
Restrictions for Datatypes 
Constraint  Description 
enumeration  Defines a list of acceptable values 
fractionDigits  Specifies the maximum number of decimal places allowed. Must be equal to or 
greater than zero 
length  Specifies the exact number of characters or list items allowed. Must be equal to 
or greater than zero 
maxExclusive  Specifies the upper bounds for numeric values (the value must be less than this 
value) 
maxInclusive  Specifies the upper bounds for numeric values (the value must be less than or 
equal to this value) 
maxLength  Specifies the maximum number of characters or list items allowed. Must be 
equal to or greater than zero 
minExclusive  Specifies the lower bounds for numeric values (the value must be greater than 
this value) 
minInclusive  Specifies the lower bounds for numeric values (the value must be greater than or 
equal to this value) 
minLength  Specifies the minimum number of characters or list items allowed. Must be equal 
to or greater than zero 
pattern  Defines the exact sequence of characters that are acceptable  

105 
 
 
totalDigits  Specifies the exact number of digits allowed. Must be greater than zero 
whiteSpace  Specifies how white space (line feeds, tabs, spaces, and carriage returns) is 
handled 

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> 

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

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"/> 
 
107 
 
 
<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" /> 

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: 
108 
 
 
<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> 

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

<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. 
Or you can give the complexType element a name, and let the "person" 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="person" type="persontype"/> 
 
<xs:complexType name="persontype"> 
  <xs:sequence> 
    <xs:element name="firstname" type="xs:string"/> 
    <xs:element name="lastname" type="xs:string"/> 
  </xs:sequence> 
</xs:complexType> 

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:extension base="basetype"> 
        .... 
        .... 
      </xs:extension> 
    </xs:simpleContent> 
110 
 
 
  </xs:complexType> 
</xs:element> 
 
OR 
 
<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. 
Here is an example of an XML element, "shoesize", that contains text‐only: 

<shoesize country="france">35</shoesize> 

The following example declares a complexType, "shoesize". The content is defined as an integer 
value, and the "shoesize" element also contains an attribute named "country": 

<xs:element name="shoesize"> 
  <xs:complexType> 
    <xs:simpleContent> 
      <xs:extension base="xs:integer"> 
        <xs:attribute name="country" type="xs:string" /> 
      </xs:extension> 
    </xs:simpleContent> 
  </xs:complexType> 
</xs:element> 

We could also give the complexType element a name, and let the "shoesize" 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="shoesize" type="shoetype"/> 
 
<xs:complexType name="shoetype"> 
  <xs:simpleContent> 
    <xs:extension base="xs:integer"> 
      <xs:attribute name="country" type="xs:string" /> 
    </xs:extension> 
111 
 
 
  </xs:simpleContent> 
</xs:complexType> 

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. 
We could also give the complexType element a name, and let the "letter" 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="letter" type="lettertype"/> 
 
<xs:complexType name="lettertype" 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> 
112 
 
 
</xs:complexType> 

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

113 
 
 
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> 
 
 
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"/> 
114 
 
 
    </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"?> 
 
<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> 
 
115 
 
 
<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> 
 
</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> 

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

Attribute Groups 

Attribute groups are defined with the attributeGroup declaration, like this: 

<xs:attributeGroup name="groupname"> 
... 
</xs:attributeGroup> 

The following example defines an attribute group named "personattrgroup": 

<xs:attributeGroup name="personattrgroup"> 
  <xs:attribute name="firstname" type="xs:string"/> 
  <xs:attribute name="lastname" type="xs:string"/> 
  <xs:attribute name="birthday" type="xs:date"/> 
</xs:attributeGroup> 

117 
 
 
After you have defined an attribute group, you can reference it in another definition, like this: 

<xs:attributeGroup name="personattrgroup"> 
  <xs:attribute name="firstname" type="xs:string"/> 
  <xs:attribute name="lastname" type="xs:string"/> 
  <xs:attribute name="birthday" type="xs:date"/> 
</xs:attributeGroup> 
 
<xs:element name="person"> 
  <xs:complexType> 
    <xs:attributeGroup ref="personattrgroup"/> 
  </xs:complexType> 
</xs:element> 

XSD The <any> Element 
 

The <any> element enables us to extend the XML document with elements not specified by the 
schema! 

 
The <any> Element 

The <any> element enables us to extend the XML document with elements not specified by the 
schema. 
The following example is a fragment from an XML schema called "family.xsd". It shows a 
declaration for the "person" element. By using the <any> element we can extend (after 
<lastname>) the content of "person" with any element: 

<xs:element name="person"> 
  <xs:complexType> 
    <xs:sequence> 
      <xs:element name="firstname" type="xs:string"/> 
      <xs:element name="lastname" type="xs:string"/> 
      <xs:any minOccurs="0"/> 
    </xs:sequence> 
  </xs:complexType> 
</xs:element> 

Now we want to extend the "person" element with a "children" element. In this case we can do 
so, even if the author of the schema above never declared any "children" element. 
Look at this schema file, called "children.xsd": 

<?xml version="1.0" encoding="ISO‐8859‐1"?> 
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
118 
 
 
targetNamespace="http://www.w3schools.com" 
xmlns="http://www.w3schools.com" 
elementFormDefault="qualified"> 
 
<xs:element name="children"> 
  <xs:complexType> 
    <xs:sequence> 
      <xs:element name="childname" type="xs:string" 
      maxOccurs="unbounded"/> 
    </xs:sequence> 
  </xs:complexType> 
</xs:element> 
 
</xs:schema> 

The XML file below (called "Myfamily.xml"), uses components from two different schemas; 
"family.xsd" and "children.xsd": 

<?xml version="1.0" encoding="ISO‐8859‐1"?> 
 
<persons xmlns="http://www.microsoft.com" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema‐instance" 
xsi:SchemaLocation="http://www.microsoft.com family.xsd 
http://www.w3schools.com children.xsd"> 
 
<person> 
  <firstname>Hege</firstname> 
  <lastname>Refsnes</lastname> 
  <children> 
    <childname>Cecilie</childname> 
  </children> 
</person> 
 
<person> 
  <firstname>Stale</firstname> 
  <lastname>Refsnes</lastname> 
</person> 
 
</persons> 

The XML file above is valid because the schema "family.xsd" allows us to extend the "person" 
element with an optional element after the "lastname" element. 
The <any> and <anyAttribute> elements are used to make EXTENSIBLE documents! They allow 
documents to contain additional elements that are not declared in the main XML schema. 

119 
 
 
XSD The <anyAttribute> Element 

The <anyAttribute> element enables us to extend the XML document with attributes not 
specified by the schema! 

 
The <anyAttribute> Element 

The <anyAttribute> element enables us to extend the XML document with attributes not 
specified by the schema. 
The following example is a fragment from an XML schema called "family.xsd". It shows a 
declaration for the "person" element. By using the <anyAttribute> element we can add any 
number of attributes to the "person" element: 

<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:anyAttribute/> 
  </xs:complexType> 
</xs:element> 

Now we want to extend the "person" element with a "gender" attribute. In this case we can do 
so, even if the author of the schema above never declared any "gender" attribute. 
Look at this schema file, called "attribute.xsd": 

<?xml version="1.0" encoding="ISO‐8859‐1"?> 
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema" 
targetNamespace="http://www.w3schools.com" 
xmlns="http://www.w3schools.com" 
elementFormDefault="qualified"> 
 
<xs:attribute name="gender"> 
  <xs:simpleType> 
    <xs:restriction base="xs:string"> 
      <xs:pattern value="male|female"/> 
    </xs:restriction> 
  </xs:simpleType> 
</xs:attribute> 
 
</xs:schema> 

The XML file below (called "Myfamily.xml"), uses components from two different schemas; 
"family.xsd" and "attribute.xsd": 
120 
 
 
<?xml version="1.0" encoding="ISO‐8859‐1"?> 
 
<persons xmlns="http://www.microsoft.com" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema‐instance" 
xsi:SchemaLocation="http://www.microsoft.com family.xsd 
http://www.w3schools.com attribute.xsd"> 
 
<person gender="female"> 
  <firstname>Hege</firstname> 
  <lastname>Refsnes</lastname> 
</person> 
 
<person gender="male"> 
  <firstname>Stale</firstname> 
  <lastname>Refsnes</lastname> 
</person> 
 
</persons> 

The XML file above is valid because the schema "family.xsd" allows us to add an attribute to the 
"person" element. 
The <any> and <anyAttribute> elements are used to make EXTENSIBLE documents! They allow 
documents to contain additional elements that are not declared in the main XML schema. 

XSD Element Substitution 

With XML Schemas, one element can substitute another element. 

 
Element Substitution 

Let's say that we have users from two different countries: England and Norway. We would like 
the ability to let the user choose whether he or she would like to use the Norwegian element 
names or the English element names in the XML document. 
To solve this problem, we could define a substitutionGroup in the XML schema. First, we 
declare a head element and then we declare the other elements which state that they are 
substitutable for the head element. 

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

In the example above, the "name" element is the head element and the "navn" element is 
substitutable for "name". 
Look at this fragment of an XML schema: 

121 
 
 
<xs:element name="name" type="xs:string"/> 
<xs:element name="navn" substitutionGroup="name"/> 
 
<xs:complexType name="custinfo"> 
  <xs:sequence> 
    <xs:element ref="name"/> 
  </xs:sequence> 
</xs:complexType> 
 
<xs:element name="customer" type="custinfo"/> 
<xs:element name="kunde" substitutionGroup="customer"/> 

A valid XML document (according to the schema above) could look like this: 

<customer> 
  <name>John Smith</name> 
</customer> 

or like this: 

<kunde> 
  <navn>John Smith</navn> 
</kunde> 
 
 
Blocking Element Substitution 

To prevent other elements from substituting with a specified element, use the block attribute: 

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

Look at this fragment of an XML schema: 

<xs:element name="name" type="xs:string" block="substitution"/> 
<xs:element name="navn" substitutionGroup="name"/> 
 
<xs:complexType name="custinfo"> 
  <xs:sequence> 
    <xs:element ref="name"/> 
  </xs:sequence> 
</xs:complexType> 
 
<xs:element name="customer" type="custinfo" block="substitution"/> 
<xs:element name="kunde" substitutionGroup="customer"/> 

A valid XML document (according to the schema above) looks like this: 
122 
 
 
<customer> 
  <name>John Smith</name> 
</customer> 

BUT THIS IS NO LONGER VALID: 

<kunde> 
  <navn>John Smith</navn> 
</kunde> 
 
 
Using substitutionGroup 

The type of the substitutable elements must be the same as, or derived from, the type of the 
head element. If the type of the substitutable element is the same as the type of the head 
element you will not have to specify the type of the substitutable element. 
Note that all elements in the substitutionGroup (the head element and the substitutable 
elements) must be declared as global elements, otherwise it will not work!  

 
What are Global Elements? 

Global elements are elements that are immediate children of the "schema" element! Local 
elements are elements nested within other elements. 

An XSD Example 

This chapter will demonstrate how to write an XML Schema. You will also learn that a schema 
can be written in different ways. 

 
An XML Document 

Let's have a look at this XML document called "shiporder.xml": 

<?xml version="1.0" encoding="ISO‐8859‐1"?> 
 
<shiporder orderid="889923" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema‐instance" 
xsi:noNamespaceSchemaLocation="shiporder.xsd"> 
  <orderperson>John Smith</orderperson> 
  <shipto> 
    <name>Ola Nordmann</name> 
    <address>Langgt 23</address> 
123 
 
 
    <city>4000 Stavanger</city> 
    <country>Norway</country> 
  </shipto> 
  <item> 
    <title>Empire Burlesque</title> 
    <note>Special Edition</note> 
    <quantity>1</quantity> 
    <price>10.90</price> 
  </item> 
  <item> 
    <title>Hide your heart</title> 
    <quantity>1</quantity> 
    <price>9.90</price> 
  </item> 
</shiporder> 

The XML document above consists of a root element, "shiporder", that contains a required 
attribute called "orderid". The "shiporder" element contains three different child elements: 
"orderperson", "shipto" and "item". The "item" element appears twice, and it contains a "title", 
an optional "note" element, a "quantity", and a "price" element. 
The line above: xmlns:xsi="http://www.w3.org/2001/XMLSchema‐instance" tells the XML 
parser that this document should be validated against a schema. The line: 
xsi:noNamespaceSchemaLocation="shiporder.xsd" specifies WHERE the schema resides (here it 
is in the same folder as "shiporder.xml"). 

 
Create an XML Schema 

Now we want to create a schema for the XML document above. 
We start by opening a new file that we will call "shiporder.xsd". To create the schema we could 
simply follow the structure in the XML document and define each element as we find it. We will 
start with the standard XML declaration followed by the xs:schema element that defines a 
schema: 

<?xml version="1.0" encoding="ISO‐8859‐1" ?> 
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
... 
</xs:schema> 

In the schema above we use the standard namespace (xs), and the URI associated with this 
namespace is the Schema language definition, which has the standard value of 
http://www.w3.org/2001/XMLSchema.  
Next, we have to define the "shiporder" element. This element has an attribute and it contains 
other elements, therefore we consider it as a complex type. The child elements of the 

124 
 
 
"shiporder" element is surrounded by a xs:sequence element that defines an ordered sequence 
of sub elements: 

<xs:element name="shiporder"> 
  <xs:complexType> 
    <xs:sequence> 
      ... 
    </xs:sequence> 
  </xs:complexType> 
</xs:element> 

Then we have to define the "orderperson" element as a simple type (because it does not 
contain any attributes or other elements). The type (xs:string) is prefixed with the namespace 
prefix associated with XML Schema that indicates a predefined schema data type: 

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

Next, we have to define two elements that are of the complex type: "shipto" and "item". We 
start by defining the "shipto" element: 

<xs:element name="shipto"> 
  <xs:complexType> 
    <xs:sequence> 
      <xs:element name="name" type="xs:string"/> 
      <xs:element name="address" type="xs:string"/> 
      <xs:element name="city" type="xs:string"/> 
      <xs:element name="country" type="xs:string"/> 
    </xs:sequence> 
  </xs:complexType> 
</xs:element> 

With schemas we can define the number of possible occurrences for an element with the 
maxOccurs and minOccurs attributes. maxOccurs specifies the maximum number of 
occurrences for an element and minOccurs specifies the minimum number of occurrences for 
an element. The default value for both maxOccurs and minOccurs is 1! 
Now we can define the "item" element. This element can appear multiple times inside a 
"shiporder" element. This is specified by setting the maxOccurs attribute of the "item" element 
to "unbounded" which means that there can be as many occurrences of the "item" element as 
the author wishes. Notice that the "note" element is optional. We have specified this by setting 
the minOccurs attribute to zero: 

<xs:element name="item" maxOccurs="unbounded"> 
  <xs:complexType> 
    <xs:sequence> 
      <xs:element name="title" type="xs:string"/> 
      <xs:element name="note" type="xs:string" minOccurs="0"/> 

125 
 
 
      <xs:element name="quantity" type="xs:positiveInteger"/> 
      <xs:element name="price" type="xs:decimal"/> 
    </xs:sequence> 
  </xs:complexType> 
</xs:element> 

We can now declare the attribute of the "shiporder" element. Since this is a required attribute 
we specify use="required". 
Note: The attribute declarations must always come last: 

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

Here is the complete listing of the schema file called "shiporder.xsd": 

<?xml version="1.0" encoding="ISO‐8859‐1" ?> 
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
 
<xs:element name="shiporder"> 
  <xs:complexType> 
    <xs:sequence> 
      <xs:element name="orderperson" type="xs:string"/> 
      <xs:element name="shipto"> 
        <xs:complexType> 
          <xs:sequence> 
            <xs:element name="name" type="xs:string"/> 
            <xs:element name="address" type="xs:string"/> 
            <xs:element name="city" type="xs:string"/> 
            <xs:element name="country" type="xs:string"/> 
          </xs:sequence> 
        </xs:complexType> 
      </xs:element> 
      <xs:element name="item" maxOccurs="unbounded"> 
        <xs:complexType> 
          <xs:sequence> 
            <xs:element name="title" type="xs:string"/> 
            <xs:element name="note" type="xs:string" minOccurs="0"/> 
            <xs:element name="quantity" type="xs:positiveInteger"/> 
            <xs:element name="price" type="xs:decimal"/> 
          </xs:sequence> 
        </xs:complexType> 
      </xs:element> 
    </xs:sequence> 
    <xs:attribute name="orderid" type="xs:string" use="required"/> 
  </xs:complexType> 
</xs:element> 
 
126 
 
 
</xs:schema> 
 
 
Divide the Schema 

The previous design method is very simple, but can be difficult to read and maintain when 
documents are complex. 
The next design method is based on defining all elements and attributes first, and then 
referring to them using the ref attribute. 
Here is the new design of the schema file ("shiporder.xsd"): 

<?xml version="1.0" encoding="ISO‐8859‐1" ?> 
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
 
<!‐‐ definition of simple elements ‐‐> 
<xs:element name="orderperson" type="xs:string"/> 
<xs:element name="name" type="xs:string"/> 
<xs:element name="address" type="xs:string"/> 
<xs:element name="city" type="xs:string"/> 
<xs:element name="country" type="xs:string"/> 
<xs:element name="title" type="xs:string"/> 
<xs:element name="note" type="xs:string"/> 
<xs:element name="quantity" type="xs:positiveInteger"/> 
<xs:element name="price" type="xs:decimal"/> 
 
<!‐‐ definition of attributes ‐‐> 
<xs:attribute name="orderid" type="xs:string"/> 
 
<!‐‐ definition of complex elements ‐‐> 
<xs:element name="shipto"> 
  <xs:complexType> 
    <xs:sequence> 
      <xs:element ref="name"/> 
      <xs:element ref="address"/> 
      <xs:element ref="city"/> 
      <xs:element ref="country"/> 
    </xs:sequence> 
  </xs:complexType> 
</xs:element> 
 
<xs:element name="item"> 
  <xs:complexType> 
    <xs:sequence> 
      <xs:element ref="title"/> 
      <xs:element ref="note" minOccurs="0"/> 

127 
 
 
      <xs:element ref="quantity"/> 
      <xs:element ref="price"/> 
    </xs:sequence> 
  </xs:complexType> 
</xs:element> 
 
<xs:element name="shiporder"> 
  <xs:complexType> 
    <xs:sequence> 
      <xs:element ref="orderperson"/> 
      <xs:element ref="shipto"/> 
      <xs:element ref="item" maxOccurs="unbounded"/> 
    </xs:sequence> 
    <xs:attribute ref="orderid" use="required"/> 
  </xs:complexType> 
</xs:element> 
 
</xs:schema> 
 
 
Using Named Types 

The third design method defines classes or types, that enables us to reuse element definitions. 
This is done by naming the simpleTypes and complexTypes elements, and then point to them 
through the type attribute of the element. 
Here is the third design of the schema file ("shiporder.xsd"): 

<?xml version="1.0" encoding="ISO‐8859‐1" ?> 
<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> 
 
<xs:simpleType name="stringtype"> 
  <xs:restriction base="xs:string"/> 
</xs:simpleType> 
 
<xs:simpleType name="inttype"> 
  <xs:restriction base="xs:positiveInteger"/> 
</xs:simpleType> 
 
<xs:simpleType name="dectype"> 
  <xs:restriction base="xs:decimal"/> 
</xs:simpleType> 
 
<xs:simpleType name="orderidtype"> 
  <xs:restriction base="xs:string"> 
    <xs:pattern value="[0‐9]{6}"/> 

128 
 
 
  </xs:restriction> 
</xs:simpleType> 
 
<xs:complexType name="shiptotype"> 
  <xs:sequence> 
    <xs:element name="name" type="stringtype"/> 
    <xs:element name="address" type="stringtype"/> 
    <xs:element name="city" type="stringtype"/> 
    <xs:element name="country" type="stringtype"/> 
  </xs:sequence> 
</xs:complexType> 
 
<xs:complexType name="itemtype"> 
  <xs:sequence> 
    <xs:element name="title" type="stringtype"/> 
    <xs:element name="note" type="stringtype" minOccurs="0"/> 
    <xs:element name="quantity" type="inttype"/> 
    <xs:element name="price" type="dectype"/> 
  </xs:sequence> 
</xs:complexType> 
 
<xs:complexType name="shipordertype"> 
  <xs:sequence> 
    <xs:element name="orderperson" type="stringtype"/> 
    <xs:element name="shipto" type="shiptotype"/> 
    <xs:element name="item" maxOccurs="unbounded" type="itemtype"/> 
  </xs:sequence> 
  <xs:attribute name="orderid" type="orderidtype" use="required"/> 
</xs:complexType> 
 
<xs:element name="shiporder" type="shipordertype"/> 
 
</xs:schema> 

The restriction element indicates that the datatype is derived from a W3C XML Schema 
namespace datatype. So, the following fragment means that the value of the element or 
attribute must be a string value: 

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

The restriction element is more often used to apply restrictions to elements. Look at the 
following lines from the schema above: 

<xs:simpleType name="orderidtype"> 
  <xs:restriction base="xs:string"> 
    <xs:pattern value="[0‐9]{6}"/> 
129 
 
 
  </xs:restriction> 
</xs:simpleType> 

This indicates that the value of the element or attribute must be a string, it must be exactly six 
characters in a row, and those characters must be a number from 0 to 9. 

XSD String Data Types 

String data types are used for values that contains character strings. 

 
String Data Type 

The string data type can contain characters, line feeds, carriage returns, and tab characters. 
The following is an example of a string declaration in a schema: 

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

An element in your document might look like this: 

<customer>John Smith</customer> 

Or it might look like this: 

<customer>       John Smith     </customer> 

Note: The XML processor will not modify the value if you use the string data type. 

 
NormalizedString Data Type 

The normalizedString data type is derived from the String data type. 
The normalizedString data type also contains characters, but the XML processor will remove 
line feeds, carriage returns, and tab characters. 
The following is an example of a normalizedString declaration in a schema: 

<xs:element name="customer" type="xs:normalizedString"/> 

An element in your document might look like this: 

<customer>John Smith</customer> 

Or it might look like this: 

<customer>     John Smith     </customer> 
130 
 
 
Note: In the example above the XML processor will replace the tabs with spaces. 

 
Token Data Type 

The token data type is also derived from the String data type. 
The token data type also contains characters, but the XML processor will remove line feeds, 
carriage returns, tabs, leading and trailing spaces, and multiple spaces. 
The following is an example of a token declaration in a schema: 

<xs:element name="customer" type="xs:token"/> 

An element in your document might look like this: 

<customer>John Smith</customer> 

Or it might look like this: 

<customer>     John Smith     </customer> 

Note: In the example above the XML processor will remove the tabs. 

 
String Data Types 

Note that all of the data types below derive from the String data type (except for string itself)! 

Name  Description 
ENTITIES    
ENTITY    
ID  A string that represents the ID attribute in XML (only used with schema 
attributes) 
IDREF  A string that represents the IDREF attribute in XML (only used with 
schema attributes) 
IDREFS    
language  A string that contains a valid language id 
Name  A string that contains a valid XML name 
NCName    
NMTOKEN  A string that represents the NMTOKEN attribute in XML (only used with 
schema attributes) 
NMTOKENS    
normalizedString  A string that does not contain line feeds, carriage returns, or tabs 
QName    

131 
 
 
string  A string 
token  A string that does not contain line feeds, carriage returns, tabs, leading or 
trailing spaces, or multiple spaces 
 
 
Restrictions on String Data Types 

Restrictions that can be used with String data types: 

• enumeration 
• length 
• maxLength 
• minLength 
• pattern (NMTOKENS, IDREFS, and ENTITIES cannot use this constraint) 
• whiteSpace 

XSD Date and Time Data Types 

Date and time data types are used for values that contain date and time. 

 
Date Data Type 

The date data type is used to specify a date. 
The date is specified in the following form "YYYY‐MM‐DD" where: 

• YYYY indicates the year 
• MM indicates the month 
• DD indicates the day 

Note: All components are required! 
The following is an example of a date declaration in a schema: 

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

An element in your document might look like this: 

<start>2002‐09‐24</start> 

Time Zones 

To specify a time zone, you can either enter a date in UTC time by adding a "Z" behind the date 
‐ like this: 

132 
 
 
<start>2002‐09‐24Z</start> 

or you can specify an offset from the UTC time by adding a positive or negative time behind the 
date ‐ like this: 

<start>2002‐09‐24‐06:00</start> 
 
or 
 
<start>2002‐09‐24+06:00</start> 
 
 
Time Data Type 

The time data type is used to specify a time. 
The time is specified in the following form "hh:mm:ss" where: 

• hh indicates the hour 
• mm indicates the minute 
• ss indicates the second 

Note: All components are required! 
The following is an example of a time declaration in a schema: 

<xs:element name="start" type="xs:time"/> 

An element in your document might look like this: 

<start>09:00:00</start> 

Or it might look like this: 

<start>09:30:10.5</start> 

Time Zones 

To specify a time zone, you can either enter a time in UTC time by adding a "Z" behind the time 
‐ like this: 

<start>09:30:10Z</start> 

or you can specify an offset from the UTC time by adding a positive or negative time behind the 
time ‐ like this: 

<start>09:30:10‐06:00</start> 
 
133 
 
 
or 
 
<start>09:30:10+06:00</start> 
 
 
DateTime Data Type 

The dateTime data type is used to specify a date and a time. 
The dateTime is specified in the following form "YYYY‐MM‐DDThh:mm:ss" where: 

• YYYY indicates the year 
• MM indicates the month 
• DD indicates the day 
• T indicates the start of the required time section 
• hh indicates the hour 
• mm indicates the minute 
• ss indicates the second 

Note: All components are required! 
The following is an example of a dateTime declaration in a schema: 

<xs:element name="startdate" type="xs:dateTime"/> 

An element in your document might look like this: 

<startdate>2002‐05‐30T09:00:00</startdate> 

Or it might look like this: 

<startdate>2002‐05‐30T09:30:10.5</startdate> 

Time Zones 

To specify a time zone, you can either enter a dateTime in UTC time by adding a "Z" behind the 
time ‐ like this: 

<startdate>2002‐05‐30T09:30:10Z</startdate> 

or you can specify an offset from the UTC time by adding a positive or negative time behind the 
time ‐ like this: 

<startdate>2002‐05‐30T09:30:10‐06:00</startdate> 
 
or 
 
<startdate>2002‐05‐30T09:30:10+06:00</startdate> 
134 
 
 
 
 
Duration Data Type 

The duration data type is used to specify a time interval. 
The time interval is specified in the following form "PnYnMnDTnHnMnS" where: 

• P indicates the period (required) 
• nY indicates the number of years 
• nM indicates the number of months 
• nD indicates the number of days 
• T indicates the start of a time section (required if you are going to specify hours, 
minutes, or seconds) 
• nH indicates the number of hours 
• nM indicates the number of minutes 
• nS indicates the number of seconds 

The following is an example of a duration declaration in a schema: 

<xs:element name="period" type="xs:duration"/> 

An element in your document might look like this: 

<period>P5Y</period> 

The example above indicates a period of five years. 
Or it might look like this: 

<period>P5Y2M10D</period> 

The example above indicates a period of five years, two months, and 10 days. 
Or it might look like this: 

<period>P5Y2M10DT15H</period> 

The example above indicates a period of five years, two months, 10 days, and 15 hours. 
Or it might look like this: 

<period>PT15H</period> 

The example above indicates a period of 15 hours. 

Negative Duration 

To specify a negative duration, enter a minus sign before the P: 

135 
 
 
<period>‐P10D</period> 

The example above indicates a period of minus 10 days. 

 
Date and Time Data Types 
Name  Description 
date  Defines a date value 
dateTime  Defines a date and time value 
duration  Defines a time interval 
gDay  Defines a part of a date ‐ the day (DD) 
gMonth  Defines a part of a date ‐ the month (MM) 
gMonthDay  Defines a part of a date ‐ the month and day (MM‐DD) 
gYear  Defines a part of a date ‐ the year (YYYY) 
gYearMonth  Defines a part of a date ‐ the year and month (YYYY‐MM) 
time  Defines a time value 
 
 
Restrictions on Date Data Types 

Restrictions that can be used with Date data types: 

• enumeration 
• maxExclusive 
• maxInclusive 
• minExclusive 
• minInclusive 
• pattern 
• whiteSpace 

XSD Numeric Data Types 

Decimal data types are used for numeric values. 

 
Decimal Data Type 

The decimal data type is used to specify a numeric value. 
The following is an example of a decimal declaration in a schema: 

<xs:element name="prize" type="xs:decimal"/> 

136 
 
 
An element in your document might look like this: 

<prize>999.50</prize> 

Or it might look like this: 

<prize>+999.5450</prize> 

Or it might look like this: 

<prize>‐999.5230</prize> 

Or it might look like this: 

<prize>0</prize> 

Or it might look like this: 

<prize>14</prize> 

Note: The maximum number of decimal digits you can specify is 18. 

 
Integer Data Type 

The integer data type is used to specify a numeric value without a fractional component. 
The following is an example of an integer declaration in a schema: 

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

An element in your document might look like this: 

<prize>999</prize> 

Or it might look like this: 

<prize>+999</prize> 

Or it might look like this: 

<prize>‐999</prize> 

Or it might look like this: 

<prize>0</prize> 
 
137 
 
 
 
Numeric Data Types 

Note that all of the data types below derive from the Decimal data type (except for decimal 
itself)! 

Name  Description 
byte  A signed 8‐bit integer 
decimal  A decimal value 
int  A signed 32‐bit integer 
integer  An integer value 
long  A signed 64‐bit integer 
negativeInteger  An integer containing only negative values (..,‐2,‐1) 
nonNegativeInteger  An integer containing only non‐negative values (0,1,2,..) 
nonPositiveInteger  An integer containing only non‐positive values (..,‐2,‐1,0) 
positiveInteger  An integer containing only positive values (1,2,..) 
short  A signed 16‐bit integer 
unsignedLong  An unsigned 64‐bit integer 
unsignedInt  An unsigned 32‐bit integer 
unsignedShort  An unsigned 16‐bit integer 
unsignedByte  An unsigned 8‐bit integer 
 
 
Restrictions on Numeric Data Types 

Restrictions that can be used with Numeric data types: 

• enumeration 
• fractionDigits 
• maxExclusive 
• maxInclusive 
• minExclusive 
• minInclusive 
• pattern 
• totalDigits 
• whiteSpace 

XSD Miscellaneous Data Types 

Other miscellaneous data types are boolean, base64Binary, hexBinary, float, double, anyURI, 
QName, and NOTATION. 

 
138 
 
 
Boolean Data Type 

The boolean data type is used to specify a true or false value. 
The following is an example of a boolean declaration in a schema: 

<xs:attribute name="disabled" type="xs:boolean"/> 

An element in your document might look like this: 

<prize disabled="true">999</prize> 

Note: Legal values for boolean are true, false, 1 (which indicates true), and 0 (which indicates 
false). 

 
Binary Data Types 

Binary data types are used to express binary‐formatted data. 
We have two binary data types: 

• base64Binary (Base64‐encoded binary data) 
• hexBinary (hexadecimal‐encoded binary data) 

The following is an example of a hexBinary declaration in a schema: 

<xs:element name="blobsrc" type="xs:hexBinary"/> 
 
 
AnyURI Data Type 

The anyURI data type is used to specify a URI. 
The following is an example of an anyURI declaration in a schema: 

<xs:attribute name="src" type="xs:anyURI"/> 

An element in your document might look like this: 

<pic src="http://www.w3schools.com/images/smiley.gif" /> 

Note: If a URI has spaces, replace them with %20. 

 
Miscellaneous Data Types 
Name  Description 

139 
 
 
anyURI    
base64Binary    
boolean    
double    
float    
hexBinary    
NOTATION    
QName    
 
 
Restrictions on Miscellaneous Data Types 

Restrictions that can be used with the other data types: 

• enumeration (a Boolean data type cannot use this constraint) 
• length (a Boolean data type cannot use this constraint) 
• maxLength (a Boolean data type cannot use this constraint) 
• minLength (a Boolean data type cannot use this constraint) 
• pattern 
• whiteSpace 

XML Editors 

If you are serious about XML, you will benefit from using a professional XML Editor. 

 
XML is Text‐based 

XML is a text‐based markup language. 
One great thing about XML is that XML files can be created and edited using a simple text‐
editor like Notepad. 
However, when you start working with XML, you will soon find that it is better to edit XML 
documents using a professional XML editor. 

 
Why Not Notepad? 

Many web developers use Notepad to edit both HTML and XML documents because Notepad is 
included with the most common OS and it is simple to use. Personally I often use Notepad for 
quick editing of simple HTML, CSS, and XML files. 
But, if you use Notepad for XML editing, you will soon run into problems. 
Notepad does not know that you are writing XML, so it will not be able to assist you.  

140 
 
 
 
Why an XML Editor? 

Today XML is an important technology, and development projects use XML‐based technologies 
like: 

• XML Schema to define XML structures and data types 
• XSLT to transform XML data 
• SOAP to exchange XML data between applications 
• WSDL to describe web services 
• RDF to describe web resources 
• XPath and XQuery to access XML data 
• SMIL to define graphics 

To be able to write error‐free XML documents, you will need an intelligent XML editor! 

 
XML Editors 

Professional XML editors will help you to write error‐free XML documents, validate your XML 
against a DTD or a schema, and force you to stick to a valid XML structure. 
An XML editor should be able to: 

• Add closing tags to your opening tags automatically 
• Force you to write valid XML 
• Verify your XML against a DTD 
• Verify your XML against a Schema 
• Color code your XML syntax 
 
 
 

XML Processing 

• SAX (Simple API for XML). Low‐level approach viewing an XML document as a sequence 
of tags to which actions are assigned.  

<svg ...> <circle .../> <rect .../> <rect .../> </svg>  

• DOM (Document Object Model) Views a document as a hierarchy of elements.  

             <svg ...> </svg>   
                      |   
      +‐‐‐‐‐‐‐‐‐‐‐‐‐‐‐+‐‐‐‐‐‐‐‐‐‐‐‐‐+   

141 
 
 
      |               |             |   
<circle .../>   <rect .../>   <rect .../>  

• XSLT (Extensible Stylesheet Language Transformation) Provides a template‐oriented 
instead of procedural‐oriented approach  
• JDOM (Java Document Object Model): a variant of DOM adjusted for streamlined for 
java.  
• JAXB (Java API for XML Building): XML translation into java classes 

<svg xmlns="http://www.w3.org/2000/svg" >  
  <circle cx="50" cy="50" r="40" fill="yellow"/>  
  <rect   x="50"  y="50"  width="40" height="40" fill="green"/>  
  <rect   x="10"  y="10"  width="40" height="40" fill="green"/>  
</svg>  
<..svg into java graphics..> 

 if( QName.equals( "rect" ) ){  
     g.setColor( Color.getColor( atts.getValue("fill") ));  
     g.fillRect(  
       Integer.getInteger( atts.getValue( "x"    )).intValue(),  
       Integer.getInteger( atts.getValue( "y"    )).intValue(),  
       Integer.getInteger( atts.getValue("width" )).intValue(),  
       Integer.getInteger( atts.getValue("height")).intValue()  
     );  
 } else if( QName.equals( "circle" ) ){  
     g.setColor( Color.getColor( atts.getValue("fill") ));  
     int r = Integer.getInteger( atts.getValue("r")).intValue();  
     g.fillRect(  
       Integer.getInteger( atts.getValue( "cx" )).intValue() ‐ r,  
       Integer.getInteger( atts.getValue( "cy" )).intValue() ‐ r,  
       2*r, 2*r  
     );  
 } 

‐_‐_‐  

<..MySVGBrowser.java..> 

 import javax.xml.parsers.*;  
 import org.xml.sax.XMLReader;  
 import java.io.File;  
 import org.xml.sax.Attributes;  
142 
 
 
 import org.xml.sax.helpers.DefaultHandler;  
   
 import java.awt.*;  
 import javax.swing.*;  
   
   
 class MySVGBrowser {  
   static public void main(String[] args) {  
     new WebPage( args[0]);  
 } }  
   
 class MyContentHandler extends DefaultHandler {  
      Graphics g;  
   
   MyContentHandler(Graphics g){ this.g = g; }  
   
   public void startElement(String namespace, String localName,  
                             String QName, Attributes atts) {  
     <.svg into java graphics.>  
   }  
 }  
   
 class WebPage  extends JFrame {  
      String fileName;  
   
    WebPage ( String fileName) {  
      this.fileName = fileName;  
      setSize(200,200); setVisible(true);  
    }  
    public void paint(Graphics g) {  
      try{  
         SAXParserFactory factory = SAXParserFactory.newInstance();  
         factory.setNamespaceAware( true );  
         SAXParser saxParser = factory.newSAXParser();  
         XMLReader xmlReader = saxParser.getXMLReader();  
         xmlReader.setContentHandler( new MyContentHandler(g) );  
         xmlReader.parse( new File(fileName).toURL().toString() );  
      } catch( Exception  e ){}  
    }  
 } 
143 
 
 
‐_‐_‐  

The painting componnet is similar to that in the following program.  

<..JavaPaint.java..> 

 import java.awt.*;  
 import javax.swing.*;  
   
 class JavaPaint {  
    public static void main(String args[]) {  
      new Pic();  
    }  
 }  
 class Pic extends JFrame {  
    Pic() { setSize(200,200); setVisible(true); }  
    public void paint(Graphics g) {  
       g.fillRect(0, 0, 50, 60);  
    }  
 } 

Specifications 

• Entities and Unicode‐‐data representation  
• XML namespaces‐‐mixed vocabularies  
• DTDs, XML schemas, RELAX NG‐‐structural constraints and data types  
• XLinks, XPointers, XPath‐‐Linking and addressing  
• CSS, XSL‐FO‐‐Presentation of XML  
• Web Accessibility 

<or:oranges xmlns:or="fruit://osu/or"  
            xmlns:ap="fruit://osu/ap" >  
  <ap:apples  count="3" >...</ap:apples>  
  <cocktail   or:count="5" ap:count="2" >...</cocktail>  
</or:oranges>  
 
How SAX processing works 

144 
 
 

   
SAX analyzes an XML stream as it goes by, much like an old tickertape. Consider the 
following XML code snippet: 
<?xml version="1.0"?> 
<samples> 
<server>UNIX</server> 
<monitor>color</monitor> 
</samples> 
A SAX processor analyzing this code snipped would generate, in general, the following 
events: 
Start document 
Start element (samples) 
Characters (white space) 
Start element (server) 
Characters (UNIX) 
End element (server) 
Characters (white space) 
Start element (monitor) 
145 
 
 
Characters (color) 
End element (monitor) 
Characters (white space) 
End element (samples) 
The SAX API allows a developer to capture these events and act on them. 
SAX processing involves the following steps: 
* Create an event handler. 
* Create the SAX parser. 
* Assign the event handler to the parser. 
* Parse the document, sending each event to the handler. 
The pros and cons of event‐based processing 
The advantages of this kind of processing are much like the advantages of streaming media; 
analysis can get started immediately, rather than having to wait for all of the data to be 
processed. Also, because the application is simply examining the data as it goes by, it 
doesn't need to store it in memory. This is a huge advantage when it comes to large 
documents. In general, SAX is also much faster than the alternative, the Document Object 
Model. 
On the other hand, because the application is not storing the data in any way, it is impossible 
to make changes to it using SAX, or to move "backward" in the data stream. 
Presented by developerWorks, your source for great tutorials ibm.com/developerWorks 
Understanding SAX Page 4 
DOM and tree‐based processing 

 
 

146 
 
 

 
The Document Object Model, or DOM, is the "traditional" way of handling XML data. With DOM 
the data is loaded into memory in a tree‐like structure. 
147 
 
 
For instance, the same document used as an example in the preceding panel would be 
represented as nodes, as shown to the left. The rectangular boxes represent element nodes, 
and the ovals represent text nodes. DOM uses a root node and parent‐child relationships. For 
instance, in this case, samples 
would be the root node with five children: three text nodes (the white space), and the two 
element nodes, server and monitor. One important thing to realize is that the server 
and monitor actually have values of null. 
Instead, they have text nodes for children, UNIX 0and color. 
Pros and cons of tree‐based processing 
DOM, and by extension tree‐based processing, has several advantages. First, because the 
tree is persistent in memory, it can be modified so an application can make changes to the 
data and the structure. It can also work its way up and down the tree at any time, as opposed 
to the "one‐shot deal" of SAX. DOM can also be much simpler to use. 
On the other hand, there is a lot of overhead involved in building these trees in memory. It's 
not unusual for large files to completely overrun a system's capacity. In addition, creating a 
DOM tree can be a very slow process. 
How to choose between SAX and DOM 
Whether you choose DOM or SAX is going to depend on several factors: 
* Purpose of the application: If you are going to have to make changes to the data and 
output it as XML, then in most cases, DOM is the way to go. This is particularly true if 
the changes are to the data itself, as opposed to a simple structural change that can be 
accomplished with XSL transformations. 
* Amount of data: For large files, SAX is a better bet. 
* How the data will be used: If only a small amount of the data will actually be used, you 
may be better off using SAX to extract it into your application. On the other hand, if you 
Presented by developerWorks, your source for great tutorials ibm.com/developerWorks 
Understanding SAX Page 5 
know that you will need to refer back to information that has already been processed, 
SAX is probably not the right choice. 
* The need for speed: SAX implementations are normally faster than DOM 
implementations. 
It's important to remember that SAX and DOM are not mutually exclusive. You can use DOM 
to create a SAX stream of events, and you can use SAX to create a DOM tree. In fact, most 
parsers used to create DOM trees are actually using SAX to do it! 
Presented by developerWorks, your source for great tutorials ibm.com/developerWorks 
Understanding SAX Page 6 
 
Disadvantages of SAX are: 

  * Easily forgets previous elements it worked on 
  * Not easy to re‐order elements 
  * Cannot validate an XML document 
  * Canot easily verify ID‐REF links 

148 
 
 
DOM versus SAX parsing:  

Practical differences are the following 

1. DOM APIs map the XML document into  an internal tree structure and allows you to 
refer to the nodes and the elements in any way you want and as many times as you 
want. This usually means less programming and planning ahead but also means bad 
performance in terms of memory or CPU cycles.  
2. SAX   APIs on the other hand are event based ie they traverse the XML document and 
allows you to trap the events as it passes through the document. You can trap start of 
the document, start of an element and the start of any characters within an element. 
This usually means more programming and planning on your part but is compensated by 
the fact that it will take less memory and less CPU cycles.  
3. DOM performance may not be an issue if it used in a batch environment because the 
performance impact will be felt once and may be negligible compared to the rest of the 
batch process.  
4. DOM performance may become an issue in an on line transaction processing 
environment because the performance impact will be felt for each and every 
transaction. It may not be negligible compared to the rest of the on line processing, 
since by nature they are short living process.  
5. Elapsed time difference in DOM vs SAX  

A XML document 13kb long with  2354 elements or tags. This message represents an 
accounting G/L entries sent from one Banking system to another. 

Windows 2000 running in Pentium  

SAX version ‐   1 sec 

DOM version ‐   4 secs 

IBM mainframe under CICS 1.3 

SAX version‐     2 secs 

DOM version     10 secs 

IBM mainframe under CICS 2.2 

SAX version‐    1 sec 

DOM version     2 secs 

The significant reduction in under CICS2.2 is due to the fact that the JVM is reusable and 
it uses jdk1.3 vs jdk1.1 
149 
 
 
6. Examples of the difference in coding  

Sample XML Document 
<?xml version="1.0"?> 
<doc> 
<para>3R Computer XML Help Page</para> 
</doc> 
 
 
 
 
 
 
PRESENTATION TECHNOLOGIES IN XML 

The Extensible Stylesheet Language Family (XSL) 

XSL is a family of recommendations for defining XML document transformation and 
presentation. It consists of three parts: 

XSL Transformations (XSLT) 

a language for transforming XML 

the XML Path Language (XPath) 

an expression language used by XSLT to access or refer to parts of an XML document. 
(XPath is also used by the XML Linking specification) 

XSL Formatting Objects (XSL‐FO) 

an XML vocabulary for specifying formatting semantics 

An XSLT stylesheet specifies the presentation of a class of XML documents by describing how an 
instance of the class is transformed into an XML document that uses a formatting vocabulary, 
such as (X)HTML or XSL‐FO. For a more detailed explanation of how XSL works, see the What Is 
XSL page. 

For background information on style sheets, see the Web style sheets resource page. XSL is 
developed by the W3C XSL Working Group (members only) whose charter is to develop the 
next version of XSL. XSL is part of W3C's XML Activity, whose work is described in the XML 
Activity Statement. 

   Sample XSL file Sample ShoXS from sample XSL file  

<?xml version="1.0" encoding="utf‐8"?> 
150 
 
 
<xsl:stylesheet xmlns:xsl= 
"http://www.w3.org/1999/XSL/Transform"  
xmlns= 
"http://www.w3.org/TR/xhtml1/strict"  
version="1.0"> 
 
<xsl:strip‐space  
  elements="doc chapter section"/> 
<xsl:output method="xml" indent="yes"  
encoding="iso‐8859‐1"/> 
 
<xsl:template match="doc"> 
 <html> 
   <head> 
   <title> 
     <xsl:value‐of select="title"/> 
   </title> 
   </head> 
   <body> 
   <xsl:apply‐templates/> 
   </body> 
 </html> 
</xsl:template> 
 
<xsl:template match="doc/title"> 
  <h1> 
  <xsl:apply‐templates/> 
  </h1> 
</xsl:template> 
 
<xsl:template match="chapter/title"> 
  <h2> 
  <xsl:apply‐templates/> 
  </h2> 
</xsl:template> 
 
<xsl:template match="section/title"> 
  <h3> 
  <xsl:apply‐templates/> 
  </h3> 
</xsl:template> 
 
<xsl:template match="para"> 
  <p> 
  <xsl:apply‐templates/> 
  </p> 
151 
 
 
</xsl:template> 
 
<xsl:template match="note"> 
  <p class="note"> 
  <b>NOTE: </b> 
  <xsl:apply‐templates/> 
  </p> 
</xsl:template> 
 
<xsl:template match="emph"> 
  <em> 
  <xsl:apply‐templates/> 
  </em> 
</xsl:template> 
 
</xsl:stylesheet> 
     
 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
X FORMS  

XForms ‐XForms is the next generation of HTML forms. 
XForms uses XML to create input forms on the Web. 

From XForms 1.1: 

XForms is an XML application that represents the next generation of forms for the Web. XForms 
is not a free‐standing document type, but is intended to be integrated into other markup 
languages, such as XHTML, ODF or SVG. An XForms‐based web form gathers and processes XML 
data using an architecture that separates presentation, purpose and content. The underlying 
data of a form is organized into instances of data schema (though formal schema definitions are 
not required). An XForm allows processing of data to occur using three mechanisms:  

152 
 
 
• a declarative model composed of formulae for data calculations and constraints, data 
type and other property declarations, and data submission parameters  
• a view layer composed of intent‐based user interface controls  
• an imperative controller for orchestrating data manipulations, interactions between the 
model and view layers, and data submissions.  

Before you continue you should have a basic understanding of the following: 

• HTML 
• HTML Forms 
• XHTML 
• XML 

If you want to study these subjects first, find the tutorials on our Home Page. 

 
What Is XForms? 

• XForms is the next generation of HTML forms 
• XForms is richer and more flexible than HTML forms 
• XForms will be the forms standard in XHTML 2.0 
• XForms is platform and device independent 
• XForms separates data and logic from presentation 
• XForms uses XML to define form data 
• XForms stores and transports data in XML documents 
• XForms contains features like calculations and validations of forms 
• XForms reduces or eliminates the need for scripting 
• XForms is a W3C Recommendation 

 
XForms Is The Successors Of HTML Forms 

Forms are an important part of many web applications today. An HTML form makes it possible 
for web applications to accept input from a user.  

Today, ten years after HTML forms became a part of the HTML standard, web users do complex 
transactions that are starting to exceed the limitations of standard HTML forms. 

XForms provides a richer, more secure, and device independent way of handling web input. We 
should expect future web solutions to demand the use of XForms‐enabled browsers (All future 
browsers should support XForms). 

153 
 
 
XForms Separate Data From Presentation 

XForms uses XML for data definition and HTML or XHTML for data display. XForms separates 
the data logic of a form from its presentation. This way the XForms data can be defined 
independent of how the end‐user will interact with the application. 

 
XForms Uses XML To Define Form Data 

With XForms, the rules for describing and validating data are expressed in XML. 

 
XForms Uses XML To Store And Transport Data 

With XForms, the data displayed in a form are stored in an XML document, and the data 
submitted from the form, are transported over the internet using XML.  

The data content is coded in, and transported as Unicode bytes. 

 
XForms Is Device Independent 

Separating data from presentation makes XForms device independent, because the data model 
can be used for all devices. The presentation can be customized for different user interfaces, 
like mobile phones, handheld devices, and Braille readers for the blind. 

Since XForms is device independent and based on XML, it is also possible to add XForms 
elements directly into other XML applications like VoiceXML (speaking web data), WML 
(Wireless Markup Language), and SVG (Scalable Vector Graphics). 

The XForms Framework 

The purpose of an HTML form is to collect data. XForms has the same purpose. 

With XForms, input data is described in two different parts: 

• The XForm model ‐ defines what the form is, what it should do, what data it contains 
• The XForm user interface ‐ defines the input fields and how they should be displayed 

154 
 
 
The XForms Model 

The XForms model describes the data. 

The XForms model defines a data model inside a model element:  

<model> 
  <instance> 
    <person> 
      <fname/> 
      <lname/> 
    </person> 
  </instance> 
  <submission id="form1" action="submit.asp" method="get"/> 
</model> 

In the example above, the XForms model uses an instance element to define the XML‐template 
for the data to be collected, and a submission element to describe how to submit the data. 

Note: The XForms model does not say anything about the visual part of the form (the user 
interface). 

 
XForms Namespace 

If you are missing the XForms namespace in these examples, or if you don't know what a 
namespace is, it will be introduced in the next chapter. 

 
The instance Element 

The instance element defines the data to be collected. 

XForms is always collecting data for an XML document. The instance element in the XForms 
model defines the XML document. 

In the example above the "data instance" (the XML document) the form is collecting data for 
looks like this: 

<person> 
  <fname/> 
  <lname/> 
155 
 
 
</person> 

After collecting the data, the XML document might look like this: 

<person> 
  <fname>John</fname> 
  <lname>Smith</lname> 
</person> 

 
The submission Element 

The submission element describes how to submit the data. 

The submission element defines a form and how it should be submitted. 

In the example above, the id="form1" identifies a form, the action="submit.asp" defines the 
URL to where the form should be submitted, and the method="get" attribute defines the 
method to use when submitting the form data. 

 
The XForms User Interface 

The XForms user interface defines the input fields and how they should be displayed.  

The user interface elements are called controls (or input controls): 

<input ref="fname"><label>First Name</label></input>
<input ref="lname"><label>Last Name</label></input> 
<submit submission="form1"><label>Submit</label></submit> 

In the example above the two <input> elements define two input fields. The ref="fname" and 
ref="lname" attributes point to the <fname> and <lname> elements in the XForms model. 

The <submit> element has a submission="form1" attribute which refers to the <submission> 
element in the XForms model. A submit element is usually displayed as a button. 

Notice the <label> elements in the example. With XForms every input control element has a 
required <label> element. 

156 
 
 
XForms Example 

You can test XForms with Internet Explorer (XForms will not work in IE prior version 5). 

Just click on the "Try it Yourself" button under the example. 

Example 
<xforms> 
 
<model> 
<instance> 
<person> 
<fname/> 
<lname/> 
</person> 
</instance> 
<submission id="form1" method="get" 
action="submit.asp"/> 
</model> 
 
<input ref="fname"> 
<label>First Name</label></input><br /> 
 
<input ref="lname"> 
<label>Last Name</label></input><br /><br /> 
 
<submit submission="form1"> 
<label>Submit</label></submit> 
 
</xforms> 
 

HTML/XHTML Forms and XForms 
Function  HTML/XHTML Forms XForms 

Heavy reliance on scripting 
Validation and 
languages, both client‐side  XPath, W3C XML Schema 
Calculation 
(Javascript) and server‐side. 

157 
 
 
User Feedback  Scripting languages XML form model 

Server‐side process to dynamically 
Initializing Data  XML instance data 
generate form 

Data Representation  name=value pairs XML

XHTML, XHTML Mobile Profile, 
Host Language  HTML/XHTML 
SVG, etc. 

Using XForms 

• Browser  
o Native 
o Plugin 
o Javascript 
• XForms Player 
• Server‐side processing to XHTML/JavaScript/Ajax 

HTML Forms 

 
XForms 
 

158 
 
 

 
What Are
e XForms? 

Tradition
nal HTML We eb forms don't separatee the purposee from the ppresentation of a form. 
XForms, in contrast, are comprissed of separaate sections that describ
be what the form does, aand 
how the form looks. This allows for flexible p
presentation
n options, including classsic XHTML 
forms, to
o be attached to an XMLL form definition. 

The following illustraates how a single device‐independen nt XML formm definition, called the 
XForms M Model, has tthe capabilitty to work w
with a varietyy of standard
d or propriettary user 
interfacees: 

159 
 
 
The XForrms User Intterface provides a standard set of visual controls that are taargeted towaard 
replacingg today's XHTTML form co
ontrols. Thesse form conttrols are direectly usable inside XHTM
ML 
and otheer XML documents, like SSVG. Other ggroups, suchh as the Voicce Browser W Working Group, 
may alsoo independen ntly develop
p user interfaace components for XFo orms. 

An imporrtant concep pt in XFormss is that form
ms collect data, which is expressed aas XML instance 
data. Am mong other d duties, the XForms Modeel describes the structurre of the insttance data. TThis 
is importtant, since likke XML, formms represent a structureed interchannge of data. W Workflow, aauto‐
fill, and p
pre‐fill form applicationss are supporrted throughh the use of iinstance datta. 

Finally, th
here needs tto be a chan
nnel for instaance data to flow to and
d from the XFForms Proceessor. 
For this, the XForms Submit Prottocol definees how XForm ms send andd receive datta, including the 
o suspend an
ability to nd resume th he completio on of a form. 

The following illustraation summaarizes the main aspects o
of XForms:

Key Goalls of XFormss 

• Support for sttructured fo
orm data 
• A
Advanced for rms logic witthout serverr round‐trippping 
• D
Dynamic acce ess to serverr data sourcees during forrm execution 
• D
Decoupled da ata, logic and
d presentatiion 
• Seeamless inte
egration withh other XMLL tag sets 
• Richer user in
nterface to mmeet the neeeds of business, consum mer and devicce control 
applications 
• Support for h
handheld, television, and d desktop brrowsers, plus printers an
nd scanners
• Im
mproved internationalization and acccessibility 
• M
Multiple form
ms per page, and pages p per form 
• Suspend and Resume cap pabilities 
160 
 
 
 

1. What is XHTML? 

This section is informative. 

XHTML is a family of current and future document types and modules that reproduce, subset, 
and extend HTML 4 [HTML4]. XHTML family document types are XML based, and ultimately are 
designed to work in conjunction with XML‐based user agents. The details of this family and its 
evolution are discussed in more detail in [XHTMLMOD]. 

XHTML 1.0 (this specification) is the first document type in the XHTML family. It is a 
reformulation of the three HTML 4 document types as applications of XML 1.0 [XML]. It is 
intended to be used as a language for content that is both XML‐conforming and, if some simple 
guidelines are followed, operates in HTML 4 conforming user agents. Developers who migrate 
their content to XHTML 1.0 will realize the following benefits: 

• XHTML documents are XML conforming. As such, they are readily viewed, edited, and 
validated with standard XML tools. 
• XHTML documents can be written to operate as well or better than they did before in 
existing HTML 4‐conforming user agents as well as in new, XHTML 1.0 conforming user 
agents. 
• XHTML documents can utilize applications (e.g. scripts and applets) that rely upon either 
the HTML Document Object Model or the XML Document Object Model [DOM]. 
• As the XHTML family evolves, documents conforming to XHTML 1.0 will be more likely 
to interoperate within and among various XHTML environments. 

The XHTML family is the next step in the evolution of the Internet. By migrating to XHTML 
today, content developers can enter the XML world with all of its attendant benefits, while still 
remaining confident in their content's backward and future compatibility. 

1.1. What is HTML 4? 

HTML 4 [HTML4] is an SGML (Standard Generalized Markup Language) application conforming 
to International Standard ISO 8879, and is widely regarded as the standard publishing language 
of the World Wide Web. 

SGML is a language for describing markup languages, particularly those used in electronic 
document exchange, document management, and document publishing. HTML is an example of 
a language defined in SGML. 

SGML has been around since the middle 1980's and has remained quite stable. Much of this 
stability stems from the fact that the language is both feature‐rich and flexible. This flexibility, 
however, comes at a price, and that price is a level of complexity that has inhibited its adoption 
in a diversity of environments, including the World Wide Web. 

161 
 
 
HTML, as originally conceived, was to be a language for the exchange of scientific and other 
technical documents, suitable for use by non‐document specialists. HTML addressed the 
problem of SGML complexity by specifying a small set of structural and semantic tags suitable 
for authoring relatively simple documents. In addition to simplifying the document structure, 
HTML added support for hypertext. Multimedia capabilities were added later. 

In a remarkably short space of time, HTML became wildly popular and rapidly outgrew its 
original purpose. Since HTML's inception, there has been rapid invention of new elements for 
use within HTML (as a standard) and for adapting HTML to vertical, highly specialized, markets. 
This plethora of new elements has led to interoperability problems for documents across 
different platforms. 

1.2. What is XML? 

XML™ is the shorthand name for Extensible Markup Language [XML]. 

XML was conceived as a means of regaining the power and flexibility of SGML without most of 
its complexity. Although a restricted form of SGML, XML nonetheless preserves most of SGML's 
power and richness, and yet still retains all of SGML's commonly used features. 

While retaining these beneficial features, XML removes many of the more complex features of 
SGML that make the authoring and design of suitable software both difficult and costly. 

1.3. Why the need for XHTML? 

The benefits of migrating to XHTML 1.0 are described above. Some of the benefits of migrating 
to XHTML in general are: 

• Document developers and user agent designers are constantly discovering new ways to 
express their ideas through new markup. In XML, it is relatively easy to introduce new 
elements or additional element attributes. The XHTML family is designed to 
accommodate these extensions through XHTML modules and techniques for developing 
new XHTML‐conforming modules (described in the XHTML Modularization 
specification). These modules will permit the combination of existing and new feature 
sets when developing content and when designing new user agents. 
• Alternate ways of accessing the Internet are constantly being introduced. The XHTML 
family is designed with general user agent interoperability in mind. Through a new user 
agent and document profiling mechanism, servers, proxies, and user agents will be able 
to perform best effort content transformation. Ultimately, it will be possible to develop 
XHTML‐conforming content that is usable by any XHTML‐conforming user agent. 

2. Definitions 

This section is normative. 

162 
 
 
2.1. Terminology 

The following terms are used in this specification. These terms extend the definitions in 
[RFC2119] in ways based upon similar definitions in ISO/IEC 9945‐1:1990 [POSIX.1]: 

May 

With respect to implementations, the word "may" is to be interpreted as an optional 
feature that is not required in this specification but can be provided. With respect to 
Document Conformance, the word "may" means that the optional feature must not be 
used. The term "optional" has the same definition as "may". 

Must 

In this specification, the word "must" is to be interpreted as a mandatory requirement 
on the implementation or on Strictly Conforming XHTML Documents, depending upon 
the context. The term "shall" has the same definition as "must". 

Optional 

See "May". 

Reserved 

A value or behavior is unspecified, but it is not allowed to be used by Conforming 
Documents nor to be supported by Conforming User Agents. 

Shall 

See "Must". 

Should 

With respect to implementations, the word "should" is to be interpreted as an 
implementation recommendation, but not a requirement. With respect to documents, 
the word "should" is to be interpreted as recommended programming practice for 
documents and a requirement for Strictly Conforming XHTML Documents. 

Supported 

Certain facilities in this specification are optional. If a facility is supported, it behaves as 
specified by this specification. 

Unspecified 

When a value or behavior is unspecified, the specification defines no portability 
requirements for a facility on an implementation even when faced with a document that 
163 
 
 
uses the facility. A document that requires specific behavior in such an instance, rather 
than tolerating any behavior when using that facility, is not a Strictly Conforming XHTML 
Document. 

2.2. General Terms 
Attribute 

An attribute is a parameter to an element declared in the DTD. An attribute's type and 
value range, including a possible default value, are defined in the DTD. 

DTD 

A DTD, or document type definition, is a collection of XML markup declarations that, as 
a collection, defines the legal structure, elements, and attributes that are available for 
use in a document that complies to the DTD. 

Document 

A document is a stream of data that, after being combined with any other streams it 
references, is structured such that it holds information contained within elements that 
are organized as defined in the associated DTD. See Document Conformance for more 
information. 

Element 

An element is a document structuring unit declared in the DTD. The element's content 
model is defined in the DTD, and additional semantics may be defined in the prose 
description of the element. 

Facilities 

Facilities are elements, attributes, and the semantics associated with those elements 
and attributes. 

Implementation 

See User Agent. 

Parsing 

Parsing is the act whereby a document is scanned, and the information contained within 
the document is filtered into the context of the elements in which the information is 
structured. 

Rendering 

164 
 
 
Rendering is the act whereby the information in a document is presented. This 
presentation is done in the form most appropriate to the environment (e.g. aurally, 
visually, in print). 

User Agent 

A user agent is a system that processes XHTML documents in accordance with this 
specification. See User Agent Conformance for more information. 

Validation 

Validation is a process whereby documents are verified against the associated DTD, 
ensuring that the structure, use of elements, and use of attributes are consistent with 
the definitions in the DTD. 

Well‐formed 

A document is well‐formed when it is structured according to the rules defined in 
Section 2.1 of the XML 1.0 Recommendation [XML]. 

3. Normative Definition of XHTML 1.0 

This section is normative. 

3.1. Document Conformance 

This version of XHTML provides a definition of strictly conforming XHTML 1.0 documents, which 
are restricted to elements and attributes from the XML and XHTML 1.0 namespaces. See 
Section 3.1.2 for information on using XHTML with other namespaces, for instance, to include 
metadata expressed in RDF within XHTML documents. 

3.1.1. Strictly Conforming Documents 

A Strictly Conforming XHTML Document is an XML document that requires only the facilities 
described as mandatory in this specification. Such a document must meet all of the following 
criteria: 

1. It must conform to the constraints expressed in one of the three DTDs found in DTDs 
and in Appendix B. 
2. The root element of the document must be html. 
3. The root element of the document must contain an xmlns declaration for the XHTML 
namespace [XMLNS]. The namespace for XHTML is defined to be 
http://www.w3.org/1999/xhtml. An example root element might look like: 
4. <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> 

165 
 
 
5. There must be a DOCTYPE declaration in the document prior to the root element. The 
public identifier included in the DOCTYPE declaration must reference one of the three 
DTDs found in DTDs using the respective Formal Public Identifier. The system identifier 
may be changed to reflect local system conventions. 
6. <!DOCTYPE html  
7.      PUBLIC "‐//W3C//DTD XHTML 1.0 Strict//EN" 
8.      "http://www.w3.org/TR/xhtml1/DTD/xhtml1‐strict.dtd"> 
9.  
10. <!DOCTYPE html  
11.      PUBLIC "‐//W3C//DTD XHTML 1.0 Transitional//EN" 
12.      "http://www.w3.org/TR/xhtml1/DTD/xhtml1‐transitional.dtd"> 
13.  
14. <!DOCTYPE html  
15.      PUBLIC "‐//W3C//DTD XHTML 1.0 Frameset//EN" 
16.      "http://www.w3.org/TR/xhtml1/DTD/xhtml1‐frameset.dtd"> 
17. The DTD subset must not be used to override any parameter entities in the DTD. 

An XML declaration is not required in all XML documents; however XHTML document authors 
are strongly encouraged to use XML declarations in all their documents. Such a declaration is 
required when the character encoding of the document is other than the default UTF‐8 or UTF‐
16 and no encoding was determined by a higher‐level protocol. Here is an example of an 
XHTML document. In this example, the XML declaration is included. 

<?xml version="1.0" encoding="UTF‐8"?> 
<!DOCTYPE html  
     PUBLIC "‐//W3C//DTD XHTML 1.0 Strict//EN" 
    "http://www.w3.org/TR/xhtml1/DTD/xhtml1‐strict.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> 
  <head> 
    <title>Virtual Library</title> 
  </head> 
  <body> 
    <p>Moved to <a href="http://example.org/">example.org</a>.</p> 
  </body> 
</html> 

3.1.2. Using XHTML with other namespaces 

The XHTML namespace may be used with other XML namespaces as per [XMLNS], although 
such documents are not strictly conforming XHTML 1.0 documents as defined above. Work by 
W3C is addressing ways to specify conformance for documents involving multiple namespaces. 
For an example, see [XHTML+MathML]. 

The following example shows the way in which XHTML 1.0 could be used in conjunction with 
the MathML Recommendation: 

166 
 
 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> 
  <head> 
    <title>A Math Example</title> 
  </head> 
  <body> 
    <p>The following is MathML markup:</p> 
    <math xmlns="http://www.w3.org/1998/Math/MathML"> 
      <apply> <log/> 
        <logbase> 
          <cn> 3 </cn> 
        </logbase> 
        <ci> x </ci> 
      </apply> 
    </math> 
  </body> 
</html> 

The following example shows the way in which XHTML 1.0 markup could be incorporated into 
another XML namespace: 

<?xml version="1.0" encoding="UTF‐8"?> 
<!‐‐ initially, the default namespace is "books" ‐‐> 
<book xmlns='urn:loc.gov:books' 
    xmlns:isbn='urn:ISBN:0‐395‐36341‐6' xml:lang="en" lang="en"> 
  <title>Cheaper by the Dozen</title> 
  <isbn:number>1568491379</isbn:number> 
  <notes> 
    <!‐‐ make HTML the default namespace for a hypertext commentary ‐‐> 
    <p xmlns='http://www.w3.org/1999/xhtml'> 
        This is also available <a href="http://www.w3.org/">online</a>. 
    </p> 
  </notes> 
</book> 

3.2. User Agent Conformance 

A conforming user agent must meet all of the following criteria: 

1. In order to be consistent with the XML 1.0 Recommendation [XML], the user agent must 
parse and evaluate an XHTML document for well‐formedness. If the user agent claims to 
be a validating user agent, it must also validate documents against their referenced 
DTDs according to [XML]. 
2. When the user agent claims to support facilities defined within this specification or 
required by this specification through normative reference, it must do so in ways 
consistent with the facilities' definition. 

167 
 
 
3. When a user agent processes an XHTML document as generic XML, it shall only 
recognize attributes of type ID (i.e. the id attribute on most XHTML elements) as 
fragment identifiers. 
4. If a user agent encounters an element it does not recognize, it must process the 
element's content. 
5. If a user agent encounters an attribute it does not recognize, it must ignore the entire 
attribute specification (i.e., the attribute and its value). 
6. If a user agent encounters an attribute value it does not recognize, it must use the 
default attribute value. 
7. If it encounters an entity reference (other than one of the entities defined in this 
recommendation or in the XML recommendation) for which the user agent has 
processed no declaration (which could happen if the declaration is in the external subset 
which the user agent hasn't read), the entity reference should be processed as the 
characters (starting with the ampersand and ending with the semi‐colon) that make up 
the entity reference. 
8. When processing content, user agents that encounter characters or character entity 
references that are recognized but not renderable may substitute another rendering 
that gives the same meaning, or must display the document in such a way that it is 
obvious to the user that normal rendering has not taken place. 
9. White space is handled according to the following rules. The following characters are 
defined in [XML] white space characters: 
o SPACE (&#x0020;) 
o HORIZONTAL TABULATION (&#x0009;) 
o CARRIAGE RETURN (&#x000D;) 
o LINE FEED (&#x000A;) 

The XML processor normalizes different systems' line end codes into one single LINE 
FEED character, that is passed up to the application. 

The user agent must use the definition from CSS for processing whitespace characters 
[CSS2]. Note that the CSS2 recommendation does not explicitly address the issue of 
whitespace handling in non‐Latin character sets. This will be addressed in a future 
version of CSS, at which time this reference will be updated. 

Note that in order to produce a Canonical XHTML document, the rules above must be applied 
and the rules in [XMLC14N] must also be applied to the document. 

4. Differences with HTML 4 

This section is informative. 

Due to the fact that XHTML is an XML application, certain practices that were perfectly legal in 
SGML‐based HTML 4 [HTML4] must be changed. 

168 
 
 
4.1. Documents must be well‐formed 

Well‐formedness is a new concept introduced by [XML]. Essentially this means that all elements 
must either have closing tags or be written in a special form (as described below), and that all 
the elements must nest properly. 

Although overlapping is illegal in SGML, it is widely tolerated in existing browsers. 

CORRECT: nested elements. 

<p>here is an emphasized <em>paragraph</em>.</p> 

INCORRECT: overlapping elements 

<p>here is an emphasized <em>paragraph.</p></em> 

4.2. Element and attribute names must be in lower case 

XHTML documents must use lower case for all HTML element and attribute names. This 
difference is necessary because XML is case‐sensitive e.g. <li> and <LI> are different tags. 

4.3. For non‐empty elements, end tags are required 

In SGML‐based HTML 4 certain elements were permitted to omit the end tag; with the 
elements that followed implying closure. XML does not allow end tags to be omitted. All 
elements other than those declared in the DTD as EMPTY must have an end tag. Elements that 
are declared in the DTD as EMPTY can have an end tag or can use empty element shorthand 
(see Empty Elements). 

CORRECT: terminated elements 

<p>here is a paragraph.</p><p>here is another paragraph.</p> 

INCORRECT: unterminated elements 

<p>here is a paragraph.<p>here is another paragraph. 

4.4. Attribute values must always be quoted 

All attribute values must be quoted, even those which appear to be numeric. 

CORRECT: quoted attribute values 

<td rowspan="3"> 

INCORRECT: unquoted attribute values 
169 
 
 
<td rowspan=3> 

4.5. Attribute Minimization 

XML does not support attribute minimization. Attribute‐value pairs must be written in full. 
Attribute names such as compact and checked cannot occur in elements without their value 
being specified. 

CORRECT: unminimized attributes 

<dl compact="compact"> 

INCORRECT: minimized attributes 

<dl compact> 

4.6. Empty Elements 

Empty elements must either have an end tag or the start tag must end with />. For instance, 
<br/> or <hr></hr>. See HTML Compatibility Guidelines for information on ways to ensure this 
is backward compatible with HTML 4 user agents. 

CORRECT: terminated empty elements 

<br/><hr/> 

INCORRECT: unterminated empty elements 

<br><hr> 

4.7. White Space handling in attribute values 

When user agents process attributes, they do so according to Section 3.3.3 of [XML]: 

• Strip leading and trailing white space. 
• Map sequences of one or more white space characters (including line breaks) to a single 
inter‐word space. 

4.8. Script and Style elements 

In XHTML, the script and style elements are declared as having #PCDATA content. As a result, < 
and & will be treated as the start of markup, and entities such as &lt; and &amp; will be 
recognized as entity references by the XML processor to < and & respectively. Wrapping the 
content of the script or style element within a CDATA marked section avoids the expansion of 
these entities. 

170 
 
 
<script type="text/javascript"> 
<![CDATA[ 
... unescaped script content ... 
]]> 
</script> 

CDATA sections are recognized by the XML processor and appear as nodes in the Document 
Object Model, see Section 1.3 of the DOM Level 1 Recommendation [DOM]. 

An alternative is to use external script and style documents. 

4.9. SGML exclusions 

SGML gives the writer of a DTD the ability to exclude specific elements from being contained 
within an element. Such prohibitions (called "exclusions") are not possible in XML. 

For example, the HTML 4 Strict DTD forbids the nesting of an 'a' element within another 'a' 
element to any descendant depth. It is not possible to spell out such prohibitions in XML. Even 
though these prohibitions cannot be defined in the DTD, certain elements should not be 
nested. A summary of such elements and the elements that should not be nested in them is 
found in the normative Element Prohibitions. 

4.10. The elements with 'id' and 'name' attributes 

HTML 4 defined the name attribute for the elements a, applet, form, frame, iframe, img, and 
map. HTML 4 also introduced the id attribute. Both of these attributes are designed to be used 
as fragment identifiers. 

In XML, fragment identifiers are of type ID, and there can only be a single attribute of type ID 
per element. Therefore, in XHTML 1.0 the id attribute is defined to be of type ID. In order to 
ensure that XHTML 1.0 documents are well‐structured XML documents, XHTML 1.0 documents 
MUST use the id attribute when defining fragment identifiers on the elements listed above. See 
the HTML Compatibility Guidelines for information on ensuring such anchors are backward 
compatible when serving XHTML documents as media type text/html. 

Note that in XHTML 1.0, the name attribute of these elements is formally deprecated, and will 
be removed in a subsequent version of XHTML. 

4.11. Attributes with pre‐defined value sets 

HTML 4 and XHTML both have some attributes that have pre‐defined and limited sets of values 
(e.g. the type attribute of the input element). In SGML and XML, these are called enumerated 
attributes. Under HTML 4, the interpretation of these values was case‐insensitive, so a value of 
TEXT was equivalent to a value of text. Under XML, the interpretation of these values is case‐
sensitive, and in XHTML 1 all of these values are defined in lower‐case. 

171 
 
 
4.12. Entity references as hex values 

SGML and XML both permit references to characters by using hexadecimal values. In SGML 
these references could be made using either &#Xnn; or &#xnn;. In XML documents, you must 
use the lower‐case version (i.e. &#xnn;) 

5. Compatibility Issues 

This section is normative. 

Although there is no requirement for XHTML 1.0 documents to be compatible with existing user 
agents, in practice this is easy to accomplish. Guidelines for creating compatible documents can 
be found in Appendix C. 

5.1. Internet Media Type 

XHTML Documents which follow the guidelines set forth in Appendix C, "HTML Compatibility 
Guidelines" may be labeled with the Internet Media Type "text/html" [RFC2854], as they are 
compatible with most HTML browsers. Those documents, and any other document conforming 
to this specification, may also be labeled with the Internet Media Type "application/xhtml+xml" 
as defined in [RFC3236]. For further information on using media types with XHTML, see the 
informative note [XHTMLMIME]. 

A. DTDs 

This appendix is normative. 

These DTDs and entity sets form a normative part of this specification. The complete set of DTD 
files together with an XML declaration and SGML Open Catalog is included in the zip file and the 
gzip'd tar file for this specification. Users looking for local copies of the DTDs to work with 
should download and use those archives rather than using the specific DTDs referenced below. 

A.1. Document Type Definitions 

These DTDs approximate the HTML 4 DTDs. The W3C recommends that you use the 
authoritative versions of these DTDs at their defined SYSTEM identifiers when validating 
content. If you need to use these DTDs locally you should download one of the archives of this 
version. For completeness, the normative versions of the DTDs are included here: 

A.1.1. XHTML‐1.0‐Strict 

The file DTD/xhtml1‐strict.dtd is a normative part of this specification. The annotated contents 
of this file are available in this separate section for completeness. 

172 
 
 
A.1.2. XHTML‐1.0‐Transitional 

The file DTD/xhtml1‐transitional.dtd is a normative part of this specification. The annotated 
contents of this file are available in this separate section for completeness. 

A.1.3. XHTML‐1.0‐Frameset 

The file DTD/xhtml1‐frameset.dtd is a normative part of this specification. The annotated 
contents of this file are available in this separate section for completeness. 

A.2. Entity Sets 

The XHTML entity sets are the same as for HTML 4, but have been modified to be valid XML 1.0 
entity declarations. Note the entity for the Euro currency sign (&euro; or &#8364; or &#x20AC;) 
is defined as part of the special characters. 

A.2.1. Latin‐1 characters 

The file DTD/xhtml‐lat1.ent is a normative part of this specification. The annotated contents of 
this file are available in this separate section for completeness. 

A.2.2. Special characters 

The file DTD/xhtml‐special.ent is a normative part of this specification. The annotated contents 
of this file are available in this separate section for completeness. 

A.2.3. Symbols 

The file DTD/xhtml‐symbol.ent is a normative part of this specification. The annotated contents 
of this file are available in this separate section for completeness. 

B. Element Prohibitions 

This appendix is normative. 

The following elements have prohibitions on which elements they can contain (see SGML 
Exclusions). This prohibition applies to all depths of nesting, i.e. it contains all the descendant 
elements. 

must not contain other a elements. 

pre 

173 
 
 
must not contain the img, object, big, small, sub, or sup elements. 

button 

must not contain the input, select, textarea, label, button, form, fieldset, iframe or 
isindex elements. 

label 

must not contain other label elements. 

form 

must not contain other form elements. 

C. HTML Compatibility Guidelines 

This appendix is informative. 

This appendix summarizes design guidelines for authors who wish their XHTML documents to 
render on existing HTML user agents. Note that this recommendation does not define how 
HTML conforming user agents should process HTML documents. Nor does it define the meaning 
of the Internet Media Type text/html. For these definitions, see [HTML4] and [RFC2854] 
respectively. 

C.1. Processing Instructions and the XML Declaration 

Be aware that processing instructions are rendered on some user agents. Also, some user 
agents interpret the XML declaration to mean that the document is unrecognized XML rather 
than HTML, and therefore may not render the document as expected. For compatibility with 
these types of legacy browsers, you may want to avoid using processing instructions and XML 
declarations. Remember, however, that when the XML declaration is not included in a 
document, the document can only use the default character encodings UTF‐8 or UTF‐16. 

C.2. Empty Elements 

Include a space before the trailing / and > of empty elements, e.g. <br />, <hr /> and <img 
src="karen.jpg" alt="Karen" />. Also, use the minimized tag syntax for empty elements, e.g. <br 
/>, as the alternative syntax <br></br> allowed by XML gives uncertain results in many existing 
user agents. 

C.3. Element Minimization and Empty Element Content 

Given an empty instance of an element whose content model is not EMPTY (for example, an 
empty title or paragraph) do not use the minimized form (e.g. use <p> </p> and not <p />). 

174 
 
 
C.4. Embedded Style Sheets and Scripts 

Use external style sheets if your style sheet uses < or & or ]]> or ‐‐. Use external scripts if your 
script uses < or & or ]]> or ‐‐. Note that XML parsers are permitted to silently remove the 
contents of comments. Therefore, the historical practice of "hiding" scripts and style sheets 
within "comments" to make the documents backward compatible is likely to not work as 
expected in XML‐based user agents. 

C.5. Line Breaks within Attribute Values 

Avoid line breaks and multiple white space characters within attribute values. These are 
handled inconsistently by user agents. 

C.6. Isindex 

Don't include more than one isindex element in the document head. The isindex element is 
deprecated in favor of the input element. 

C.7. The lang and xml:lang Attributes 

Use both the lang and xml:lang attributes when specifying the language of an element. The 
value of the xml:lang attribute takes precedence. 

C.8. Fragment Identifiers 

In XML, URI‐references [RFC2396] that end with fragment identifiers of the form "#foo" do not 
refer to elements with an attribute name="foo"; rather, they refer to elements with an 
attribute defined to be of type ID, e.g., the id attribute in HTML 4. Many existing HTML clients 
don't support the use of ID‐type attributes in this way, so identical values may be supplied for 
both of these attributes to ensure maximum forward and backward compatibility (e.g., <a 
id="foo" name="foo">...</a>). 

Further, since the set of legal values for attributes of type ID is much smaller than for those of 
type CDATA, the type of the name attribute has been changed to NMTOKEN. This attribute is 
constrained such that it can only have the same values as type ID, or as the Name production in 
XML 1.0 Section 2.3, production 5. Unfortunately, this constraint cannot be expressed in the 
XHTML 1.0 DTDs. Because of this change, care must be taken when converting existing HTML 
documents. The values of these attributes must be unique within the document, valid, and any 
references to these fragment identifiers (both internal and external) must be updated should 
the values be changed during conversion. 

Note that the collection of legal values in XML 1.0 Section 2.3, production 5 is much larger than 
that permitted to be used in the ID and NAME types defined in HTML 4. When defining 
fragment identifiers to be backward‐compatible, only strings matching the pattern [A‐Za‐z][A‐
Za‐z0‐9:_.‐]* should be used. See Section 6.2 of [HTML4] for more information. 

175 
 
 
Finally, note that XHTML 1.0 has deprecated the name attribute of the a, applet, form, frame, 
iframe, img, and map elements, and it will be removed from XHTML in subsequent versions. 

C.9. Character Encoding 

Historically, the character encoding of an HTML document is either specified by a web server 
via the charset parameter of the HTTP Content‐Type header, or via a meta element in the 
document itself. In an XML document, the character encoding of the document is specified on 
the XML declaration (e.g., <?xml version="1.0" encoding="EUC‐JP"?>). In order to portably 
present documents with specific character encodings, the best approach is to ensure that the 
web server provides the correct headers. If this is not possible, a document that wants to set its 
character encoding explicitly must include both the XML declaration an encoding declaration 
and a meta http‐equiv statement (e.g., <meta http‐equiv="Content‐type" content="text/html; 
charset=EUC‐JP" />). In XHTML‐conforming user agents, the value of the encoding declaration 
of the XML declaration takes precedence. 

Note: be aware that if a document must include the character encoding declaration in a meta 
http‐equiv statement, that document may always be interpreted by HTTP servers and/or user 
agents as being of the internet media type defined in that statement. If a document is to be 
served as multiple media types, the HTTP server must be used to set the encoding of the 
document. 

C.10. Boolean Attributes 

Some HTML user agents are unable to interpret boolean attributes when these appear in their 
full (non‐minimized) form, as required by XML 1.0. Note this problem doesn't affect user agents 
compliant with HTML 4. The following attributes are involved: compact, nowrap, ismap, 
declare, noshade, checked, disabled, readonly, multiple, selected, noresize, defer. 

C.11. Document Object Model and XHTML 

The Document Object Model level 1 Recommendation [DOM] defines document object model 
interfaces for XML and HTML 4. The HTML 4 document object model specifies that HTML 
element and attribute names are returned in upper‐case. The XML document object model 
specifies that element and attribute names are returned in the case they are specified. In 
XHTML 1.0, elements and attributes are specified in lower‐case. This apparent difference can be 
addressed in two ways: 

1. User agents that access XHTML documents served as Internet media type text/html via 
the DOM can use the HTML DOM, and can rely upon element and attribute names being 
returned in upper‐case from those interfaces. 
2. User agents that access XHTML documents served as Internet media types text/xml, 
application/xml, or application/xhtml+xml can also use the XML DOM. Elements and 
attributes will be returned in lower‐case. Also, some XHTML elements may or may not 
appear in the object tree because they are optional in the content model (e.g. the tbody 
element within table). This occurs because in HTML 4 some elements were permitted to 
176 
 
 
be minimized such that their start and end tags are both omitted (an SGML feature). 
This is not possible in XML. Rather than require document authors to insert extraneous 
elements, XHTML has made the elements optional. User agents need to adapt to this 
accordingly. For further information on this topic, see [DOM2] 

C.12. Using Ampersands in Attribute Values (and Elsewhere) 

In both SGML and XML, the ampersand character ("&") declares the beginning of an entity 
reference (e.g., &reg; for the registered trademark symbol "®"). Unfortunately, many HTML 
user agents have silently ignored incorrect usage of the ampersand character in HTML 
documents ‐ treating ampersands that do not look like entity references as literal ampersands. 
XML‐based user agents will not tolerate this incorrect usage, and any document that uses an 
ampersand incorrectly will not be "valid", and consequently will not conform to this 
specification. In order to ensure that documents are compatible with historical HTML user 
agents and XML‐based user agents, ampersands used in a document that are to be treated as 
literal characters must be expressed themselves as an entity reference (e.g. "&amp;"). For 
example, when the href attribute of the a element refers to a CGI script that takes parameters, 
it must be expressed as http://my.site.dom/cgi‐bin/myscript.pl?class=guest&amp;name=user 
rather than as http://my.site.dom/cgi‐bin/myscript.pl?class=guest&name=user. 

C.13. Cascading Style Sheets (CSS) and XHTML 

The Cascading Style Sheets level 2 Recommendation [CSS2] defines style properties which are 
applied to the parse tree of the HTML or XML documents. Differences in parsing will produce 
different visual or aural results, depending on the selectors used. The following hints will 
reduce this effect for documents which are served without modification as both media types: 

1. CSS style sheets for XHTML should use lower case element and attribute names. 
2. In tables, the tbody element will be inferred by the parser of an HTML user agent, but 
not by the parser of an XML user agent. Therefore you should always explicitly add a 
tbody element if it is referred to in a CSS selector. 
3. Within the XHTML namespace, user agents are expected to recognize the "id" attribute 
as an attribute of type ID. Therefore, style sheets should be able to continue using the 
shorthand "#" selector syntax even if the user agent does not read the DTD. 
4. Within the XHTML namespace, user agents are expected to recognize the "class" 
attribute. Therefore, style sheets should be able to continue using the shorthand "." 
selector syntax. 
5. CSS defines different conformance rules for HTML and XML documents; be aware that 
the HTML rules apply to XHTML documents delivered as HTML and the XML rules apply 
to XHTML documents delivered as XML. 

C.14. Referencing Style Elements when serving as XML 

In HTML 4 and XHTML, the style element can be used to define document‐internal style rules. 
In XML, an XML stylesheet declaration is used to define style rules. In order to be compatible 

177 
 
 
with this convention, style elements should have their fragment identifier set using the id 
attribute, and an XML stylesheet declaration should reference this fragment. For example: 

<?xml‐stylesheet href="http://www.w3.org/StyleSheets/TR/W3C‐REC.css" type="text/css"?> 
<?xml‐stylesheet href="#internalStyle" type="text/css"?> 
<!DOCTYPE html  
     PUBLIC "‐//W3C//DTD XHTML 1.0 Strict//EN" 
     "http://www.w3.org/TR/xhtml1/DTD/xhtml1‐strict.dtd"> 
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> 
<head> 
<title>An internal stylesheet example</title> 
<style type="text/css" id="internalStyle"> 
  code { 
    color: green; 
    font‐family: monospace; 
    font‐weight: bold; 
  } 
</style> 
</head> 
<body> 
<p> 
  This is text that uses our  
  <code>internal stylesheet</code>. 
</p> 
</body> 
</html> 

C.15. White Space Characters in HTML vs. XML 

Some characters that are legal in HTML documents, are illegal in XML document. For example, 
in HTML, the Formfeed character (U+000C) is treated as white space, in XHTML, due to XML's 
definition of characters, it is illegal. 

C.16. The Named Character Reference &apos; 

The named character reference &apos; (the apostrophe, U+0027) was introduced in XML 1.0 
but does not appear in HTML. Authors should therefore use &#39; instead of &apos; to work as 
expected in HTML 4 user agents. 

1. Overview 

This document defines VoiceXML, the Voice Extensible Markup Language. Its background, basic 
concepts and use are presented in Section 1. The dialog constructs of form, menu and link, and 
the mechanism (Form Interpretation Algorithm) by which they are interpreted are then 
introduced in Section 2. User input using DTMF and speech grammars is covered in Section 3, 

178 
 
 
while Section 4 covers system output using speech synthesis and recorded audio. Mechanisms 
for manipulating dialog control flow, including variables, events, and executable elements, are 
explained in Section 5. Environment features such as parameters and properties as well as 
resource handling are specified in Section 6. The appendices provide additional information 
including the VoiceXML Schema, a detailed specification of the Form Interpretation Algorithm 
and timing, audio file formats, and statements relating to conformance, internationalization, 
accessibility and privacy. 

The origins of VoiceXML began in 1995 as an XML‐based dialog design language intended to 
simplify the speech recognition application development process within an AT&T project called 
Phone Markup Language (PML). As AT&T reorganized, teams at AT&T, Lucent and Motorola 
continued working on their own PML‐like languages. 

In 1998, W3C hosted a conference on voice browsers. By this time, AT&T and Lucent had 
different variants of their original PML, while Motorola had developed VoxML, and IBM was 
developing its own SpeechML. Many other attendees at the conference were also developing 
similar languages for dialog design; for example, such as HP's TalkML and PipeBeach's 
VoiceHTML. 

The VoiceXML Forum was then formed by AT&T, IBM, Lucent, and Motorola to pool their 
efforts. The mission of the VoiceXML Forum was to define a standard dialog design language 
that developers could use to build conversational applications. They chose XML as the basis for 
this effort because it was clear to them that this was the direction technology was going. 

In 2000, the VoiceXML Forum released VoiceXML 1.0 to the public. Shortly thereafter, 
VoiceXML 1.0 was submitted to the W3C as the basis for the creation of a new international 
standard. VoiceXML 2.0 is the result of this work based on input from W3C Member companies, 
other W3C Working Groups, and the public. 

Developers familiar with VoiceXML 1.0 are particularly directed to Changes from Previous 
Public Version which summarizes how VoiceXML 2.0 differs from VoiceXML 1.0. 

1.1 Introduction 

VoiceXML is designed for creating audio dialogs that feature synthesized speech, digitized 
audio, recognition of spoken and DTMF key input, recording of spoken input, telephony, and 
mixed initiative conversations. Its major goal is to bring the advantages of Web‐based 
development and content delivery to interactive voice response applications. 

Here are two short examples of VoiceXML. The first is the venerable "Hello World": 

<?xml version="1.0" encoding="UTF‐8"?>  
<vxml xmlns="http://www.w3.org/2001/vxml"  
  xmlns:xsi="http://www.w3.org/2001/XMLSchema‐instance"  
  xsi:schemaLocation="http://www.w3.org/2001/vxml  
   http://www.w3.org/TR/voicexml20/vxml.xsd" 
179 
 
 
   version="2.0"> 
  <form> 
    <block>Hello World!</block> 
  </form> 
</vxml> 

The top‐level element is <vxml>, which is mainly a container for dialogs. There are two types of 
dialogs: forms and menus. Forms present information and gather input; menus offer choices of 
what to do next. This example has a single form, which contains a block that synthesizes and 
presents "Hello World!" to the user. Since the form does not specify a successor dialog, the 
conversation ends. 

Our second example asks the user for a choice of drink and then submits it to a server script: 

<?xml version="1.0" encoding="UTF‐8"?> 
<vxml xmlns="http://www.w3.org/2001/vxml"  
  xmlns:xsi="http://www.w3.org/2001/XMLSchema‐instance"  
  xsi:schemaLocation="http://www.w3.org/2001/vxml  
   http://www.w3.org/TR/voicexml20/vxml.xsd" 
   version="2.0"> 
  <form> 
  <field name="drink"> 
     <prompt>Would you like coffee, tea, milk, or nothing?</prompt> 
     <grammar src="drink.grxml" type="application/srgs+xml"/> 
  </field> 
  <block> 
     <submit next="http://www.drink.example.com/drink2.asp"/> 
  </block> 
 </form> 
</vxml> 

A field is an input field. The user must provide a value for the field before proceeding to the 
next element in the form. A sample interaction is: 

C (computer): Would you like coffee, tea, milk, or nothing? 

H (human): Orange juice. 

C: I did not understand what you said. (a platform‐specific default message.) 

C: Would you like coffee, tea, milk, or nothing? 

H: Tea 

C: (continues in document drink2.asp) 

180 
 
 
1.2 Background 

This section contains a high‐level architectural model, whose terminology is then used to 
describe the goals of VoiceXML, its scope, its design principles, and the requirements it places 
on the systems that support it. 

1.2.1 Architectural Model 

The architectural model assumed by this document has the following components: 

 
Figure 1: Architectural Model 

A document server (e.g. a Web server) processes requests from a client application, the 
VoiceXML Interpreter, through the VoiceXML interpreter context. The server produces 
VoiceXML documents in reply, which are processed by the VoiceXML interpreter. The VoiceXML 
interpreter context may monitor user inputs in parallel with the VoiceXML interpreter. For 
example, one VoiceXML interpreter context may always listen for a special escape phrase that 
takes the user to a high‐level personal assistant, and another may listen for escape phrases that 
alter user preferences like volume or text‐to‐speech characteristics. 

The implementation platform is controlled by the VoiceXML interpreter context and by the 
VoiceXML interpreter. For instance, in an interactive voice response application, the VoiceXML 
interpreter context may be responsible for detecting an incoming call, acquiring the initial 
VoiceXML document, and answering the call, while the VoiceXML interpreter conducts the 
dialog after answer. The implementation platform generates events in response to user actions 
(e.g. spoken or character input received, disconnect) and system events (e.g. timer expiration). 
Some of these events are acted upon by the VoiceXML interpreter itself, as specified by the 
VoiceXML document, while others are acted upon by the VoiceXML interpreter context. 

181 
 
 
1.2.2 Goals of VoiceXML 

VoiceXML's main goal is to bring the full power of Web development and content delivery to 
voice response applications, and to free the authors of such applications from low‐level 
programming and resource management. It enables integration of voice services with data 
services using the familiar client‐server paradigm. A voice service is viewed as a sequence of 
interaction dialogs between a user and an implementation platform. The dialogs are provided 
by document servers, which may be external to the implementation platform. Document 
servers maintain overall service logic, perform database and legacy system operations, and 
produce dialogs. A VoiceXML document specifies each interaction dialog to be conducted by a 
VoiceXML interpreter. User input affects dialog interpretation and is collected into requests 
submitted to a document server. The document server replies with another VoiceXML 
document to continue the user's session with other dialogs. 

VoiceXML is a markup language that: 

• Minimizes client/server interactions by specifying multiple interactions per document. 
• Shields application authors from low‐level, and platform‐specific details. 
• Separates user interaction code (in VoiceXML) from service logic (e.g. CGI scripts). 
• Promotes service portability across implementation platforms. VoiceXML is a common 
language for content providers, tool providers, and platform providers. 
• Is easy to use for simple interactions, and yet provides language features to support 
complex dialogs. 

While VoiceXML strives to accommodate the requirements of a majority of voice response 
services, services with stringent requirements may best be served by dedicated applications 
that employ a finer level of control. 

1.2.3 Scope of VoiceXML 

The language describes the human‐machine interaction provided by voice response systems, 
which includes: 

• Output of synthesized speech (text‐to‐speech). 
• Output of audio files. 
• Recognition of spoken input. 
• Recognition of DTMF input. 
• Recording of spoken input. 
• Control of dialog flow. 
• Telephony features such as call transfer and disconnect. 

The language provides means for collecting character and/or spoken input, assigning the input 
results to document‐defined request variables, and making decisions that affect the 
interpretation of documents written in the language. A document may be linked to other 
documents through Universal Resource Identifiers (URIs). 

182 
 
 
1.2.4 Principles of Design 

VoiceXML is an XML application [XML]. 

1. The language promotes portability of services through abstraction of platform 
resources. 
2. The language accommodates platform diversity in supported audio file formats, speech 
grammar formats, and URI schemes. While producers of platforms may support various 
grammar formats the language requires a common grammar format, namely the XML 
Form of the W3C Speech Recognition Grammar Specification [SRGS], to facilitate 
interoperability. Similarly, while various audio formats for playback and recording may 
be supported, the audio formats described in Appendix E must be supported 
3. The language supports ease of authoring for common types of interactions. 
4. The language has well‐defined semantics that preserves the author's intent regarding 
the behavior of interactions with the user. Client heuristics are not required to 
determine document element interpretation. 
5. The language recognizes semantic interpretations from grammars and makes this 
information available to the application. 
6. The language has a control flow mechanism. 
7. The language enables a separation of service logic from interaction behavior. 
8. It is not intended for intensive computation, database operations, or legacy system 
operations. These are assumed to be handled by resources outside the document 
interpreter, e.g. a document server. 
9. General service logic, state management, dialog generation, and dialog sequencing are 
assumed to reside outside the document interpreter. 
10. The language provides ways to link documents using URIs, and also to submit data to 
server scripts using URIs. 
11. VoiceXML provides ways to identify exactly which data to submit to the server, and 
which HTTP method (GET or POST) to use in the submittal. 
12. The language does not require document authors to explicitly allocate and deallocate 
dialog resources, or deal with concurrency. Resource allocation and concurrent threads 
of control are to be handled by the implementation platform. 

1.2.5 Implementation Platform Requirements 

This section outlines the requirements on the hardware/software platforms that will support a 
VoiceXML interpreter. 

Document acquisition. The interpreter context is expected to acquire documents for the 
VoiceXML interpreter to act on. The "http" URI scheme must be supported. In some cases, the 
document request is generated by the interpretation of a VoiceXML document, while other 
requests are generated by the interpreter context in response to events outside the scope of 
the language, for example an incoming phone call. When issuing document requests via http, 
the interpreter context identifies itself using the "User‐Agent" header variable with the value 
"<name>/<version>", for example, "acme‐browser/1.2" 

183 
 
 
Audio output. An implementation platform must support audio output using audio files and 
text‐to‐speech (TTS). The platform must be able to freely sequence TTS and audio output. If an 
audio output resource is not available, an error.noresource event must be thrown. Audio files 
are referred to by a URI. The language specifies a required set of audio file formats which must 
be supported (see Appendix E); additional audio file formats may also be supported. 

Audio input. An implementation platform is required to detect and report character and/or 
spoken input simultaneously and to control input detection interval duration with a timer 
whose length is specified by a VoiceXML document. If an audio input resource is not available, 
an error.noresource event must be thrown. 

• It must report characters (for example, DTMF) entered by a user. Platforms must 
support the XML form of DTMF grammars described in the W3C Speech Recognition 
Grammar Specification [SRGS]. They should also support the Augmented BNF (ABNF) 
form of DTMF grammars described in the W3C Speech Recognition Grammar 
Specification [SRGS]. 
• It must be able to receive speech recognition grammar data dynamically. It must be able 
to use speech grammar data in the XML Form of the W3C Speech Recognition Grammar 
Specification [SRGS]. It should be able to receive speech recognition grammar data in 
the ABNF form of the W3C Speech Recognition Grammar Specification [SRGS], and may 
support other formats such as the JSpeech Grammar Format [JSGF] or proprietary 
formats. Some VoiceXML elements contain speech grammar data; others refer to 
speech grammar data through a URI. The speech recognizer must be able to 
accommodate dynamic update of the spoken input for which it is listening through 
either method of speech grammar data specification. 
• It must be able to record audio received from the user. The implementation platform 
must be able to make the recording available to a request variable. The language 
specifies a required set of recorded audio file formats which must be supported (see 
Appendix E); additional formats may also be supported. 

Transfer The platform should be able to support making a third party connection through a 
communications network, such as the telephone. 

1.3 Concepts 

A VoiceXML document (or a set of related documents called an application) forms a 
conversational finite state machine. The user is always in one conversational state, or dialog, at 
a time. Each dialog determines the next dialog to transition to. Transitions are specified using 
URIs, which define the next document and dialog to use. If a URI does not refer to a document, 
the current document is assumed. If it does not refer to a dialog, the first dialog in the 
document is assumed. Execution is terminated when a dialog does not specify a successor, or if 
it has an element that explicitly exits the conversation. 

184 
 
 
1.3.1 Dialogs and Subdialogs 

There are two kinds of dialogs: forms and menus. Forms define an interaction that collects 
values for a set of form item variables. Each field may specify a grammar that defines the 
allowable inputs for that field. If a form‐level grammar is present, it can be used to fill several 
fields from one utterance. A menu presents the user with a choice of options and then 
transitions to another dialog based on that choice. 

A subdialog is like a function call, in that it provides a mechanism for invoking a new 
interaction, and returning to the original form. Variable instances, grammars, and state 
information are saved and are available upon returning to the calling document. Subdialogs can 
be used, for example, to create a confirmation sequence that may require a database query; to 
create a set of components that may be shared among documents in a single application; or to 
create a reusable library of dialogs shared among many applications. 

1.3.2 Sessions 

A session begins when the user starts to interact with a VoiceXML interpreter context, 
continues as documents are loaded and processed, and ends when requested by the user, a 
document, or the interpreter context. 

1.3.3 Applications 

An application is a set of documents sharing the same application root document. Whenever 
the user interacts with a document in an application, its application root document is also 
loaded. The application root document remains loaded while the user is transitioning between 
other documents in the same application, and it is unloaded when the user transitions to a 
document that is not in the application. While it is loaded, the application root document's 
variables are available to the other documents as application variables, and its grammars 
remain active for the duration of the application, subject to the grammar activation rules 
discussed in Section 3.1.4. 

Figure 2 shows the transition of documents (D) in an application that share a common 
application root document (root). 

 
Figure 2: Transitioning between documents in an application. 
185 
 
 
1.3.4 Grammars 

Each dialog has one or more speech and/or DTMF grammars associated with it. In machine 
directed applications, each dialog's grammars are active only when the user is in that dialog. In 
mixed initiative applications, where the user and the machine alternate in determining what to 
do next, some of the dialogs are flagged to make their grammars active (i.e., listened for) even 
when the user is in another dialog in the same document, or on another loaded document in 
the same application. In this situation, if the user says something matching another dialog's 
active grammars, execution transitions to that other dialog, with the user's utterance treated as 
if it were said in that dialog. Mixed initiative adds flexibility and power to voice applications. 

1.3.5 Events 

VoiceXML provides a form‐filling mechanism for handling "normal" user input. In addition, 
VoiceXML defines a mechanism for handling events not covered by the form mechanism. 

Events are thrown by the platform under a variety of circumstances, such as when the user 
does not respond, doesn't respond intelligibly, requests help, etc. The interpreter also throws 
events if it finds a semantic error in a VoiceXML document. Events are caught by catch 
elements or their syntactic shorthand. Each element in which an event can occur may specify 
catch elements. Furthermore, catch elements are also inherited from enclosing elements "as if 
by copy". In this way, common event handling behavior can be specified at any level, and it 
applies to all lower levels. 

1.3.6 Links 

A link supports mixed initiative. It specifies a grammar that is active whenever the user is in the 
scope of the link. If user input matches the link's grammar, control transfers to the link's 
destination URI. A link can be used to throw an event or go to a destination URI. 

1.4 VoiceXML Elements 
Element  Purpose Section

<assign>  Assign a variable a value 5.3.2  

<audio>  Play an audio clip within a prompt 4.1.3  

<block>  A container of (non‐interactive) executable code  2.3.2  

<catch>  Catch an event 5.2.2  

<choice>  Define a menu item 2.2.2  

186 
 
 
Element  Purpose Section

<clear>  Clear one or more form item variables 5.3.3  

<disconnect> Disconnect a session 5.3.11  

<else>  Used in <if> elements 5.3.4  

<elseif>  Used in <if> elements 5.3.4  

<enumerate>  Shorthand for enumerating the choices in a menu  2.2.4  

<error>  Catch an error event 5.2.3  

<exit>  Exit a session 5.3.9  

<field>  Declares an input field in a form 2.3.1  

<filled>  An action executed when fields are filled 2.4  

A dialog for presenting information and collecting 
<form>  2.1  
data 

Go to another dialog in the same or different 
<goto>  5.3.7  
document 

<grammar>  Specify a speech recognition or DTMF grammar 3.1  

<help>  Catch a help event 5.2.3  

<if>  Simple conditional logic 5.3.4  

Declares initial logic upon entry into a (mixed 
<initial>  2.3.3  
initiative) form 

Specify a transition common to all dialogs in the 
<link>  2.5  
link's scope 

187 
 
 
Element  Purpose Section

<log>  Generate a debug message 5.3.13  

A dialog for choosing amongst alternative 
<menu>  2.2.1
destinations 
 

<meta>  Define a metadata item as a name/value pair 6.2.1  

Define metadata information using a metadata 
<metadata>  6.2.2  
schema 

<noinput>  Catch a noinput event 5.2.3  

<nomatch>  Catch a nomatch event 5.2.3  

<object>  Interact with a custom extension 2.3.5  

<option>  Specify an option in a <field> 2.3.1.3  

<param>  Parameter in <object> or <subdialog> 6.4  

Queue speech synthesis and audio output to the 
<prompt>  4.1  
user 

<property>  Control implementation platform settings. 6.3  

<record>  Record an audio sample 2.3.6  

Play a field prompt when a field is re‐visited after an 
<reprompt>  5.3.6  
event 

<return>  Return from a subdialog. 5.3.10  

Specify a block of ECMAScript client‐side scripting 
<script>  5.3.12  
logic 

<subdialog>  Invoke another dialog as a subdialog of the current  2.3.4  

188 
 
 
Element  Purpose Section

one 

<submit>  Submit values to a document server 5.3.8  

<throw>  Throw an event. 5.2.1  

<transfer>  Transfer the caller to another destination 2.3.7  

<value>  Insert the value of an expression in a prompt 4.1.4  

<var>  Declare a variable 5.3.1  

<vxml>  Top‐level element in each VoiceXML document 1.5.1  

Table 1: VoiceXML Elements

1.5 Document Structure and Execution 

A VoiceXML document is primarily composed of top‐level elements called dialogs. There are 
two types of dialogs: forms and menus. A document may also have <meta> and <metadata> 
elements, <var> and <script> elements, <property> elements, <catch> elements, and <link> 
elements. 

1.5.1 Execution within One Document 

Document execution begins at the first dialog by default. As each dialog executes, it determines 
the next dialog. When a dialog doesn't specify a successor dialog, document execution stops. 

Here is "Hello World!" expanded to illustrate some of this. It now has a document level variable 
called "hi" which holds the greeting. Its value is used as the prompt in the first form. Once the 
first form plays the greeting, it goes to the form named "say_goodbye", which prompts the user 
with "Goodbye!" Because the second form does not transition to another dialog, it causes the 
document to be exited. 

<?xml version="1.0" encoding="UTF‐8"?> 
<vxml xmlns="http://www.w3.org/2001/vxml"  
  xmlns:xsi="http://www.w3.org/2001/XMLSchema‐instance"  
  xsi:schemaLocation="http://www.w3.org/2001/vxml  
   http://www.w3.org/TR/voicexml20/vxml.xsd" 
   version="2.0"> 
189 
 
 
 <meta name="author" content="John Doe"/> 
 <meta name="maintainer" content="hello‐support@hi.example.com"/> 
 <var name="hi" expr="'Hello World!'"/> 
 <form> 
  <block> 
     <value expr="hi"/> 
     <goto next="#say_goodbye"/> 
  </block> 
 </form> 
 <form id="say_goodbye"> 
  <block> 
     Goodbye! 
  </block> 
 </form> 
</vxml> 

Alternatively the forms can be combined: 

<?xml version="1.0" encoding="UTF‐8"?> 
<vxml xmlns="http://www.w3.org/2001/vxml"  
  xmlns:xsi="http://www.w3.org/2001/XMLSchema‐instance"  
  xsi:schemaLocation="http://www.w3.org/2001/vxml  
   http://www.w3.org/TR/voicexml20/vxml.xsd" 
   version="2.0"> 
 <meta name="author" content="John Doe"/> 
 <meta name="maintainer" content="hello‐support@hi.example.com"/> 
 <var name="hi" expr="'Hello World!'"/> 
 <form> 
  <block> 
     <value expr="hi"/> Goodbye! 
  </block> 
 </form> 
</vxml> 

Attributes of <vxml> include: 

The version of VoiceXML of this document (required). The 
version 
current version number is 2.0. 

The designated namespace for VoiceXML (required). The 
xmlns  namespace for VoiceXML is defined to be 
http://www.w3.org/2001/vxml. 

190 
 
 
The base URI for this document as defined in [XML‐BASE]. As in 
xml:base  [HTML], a URI which all relative references within the 
document take as their base. 

The language identifier for this document . If omitted, the 
xml:lang 
value is a platform‐specific default. 

application  The URI of this document's application root document, if any. 

Table 2: <vxml> Attributes

Language information is inherited down the document hierarchy: the value of "xml:lang" is 
inherited by elements which also define the "xml:lang" attribute, such as <grammar> and 
<prompt>, unless these elements specify an alternative value. 

1.5.2 Executing a Multi‐Document Application 

Normally, each document runs as an isolated application. In cases where you want multiple 
documents to work together as one application, you select one document to be the application 
root document, and the rest to be application leaf documents. Each leaf document names the 
root document in its <vxml> element. 

When this is done, every time the interpreter is told to load and execute a leaf document in this 
application, it first loads the application root document if it is not already loaded. The 
application root document remains loaded until the interpreter is told to load a document that 
belongs to a different application. Thus one of the following two conditions always holds during 
interpretation: 

• The application root document is loaded and the user is executing in it: there is no leaf 
document. 
• The application root document and a single leaf document are both loaded and the user 
is executing in the leaf document. 

If there is a chain of subdialogs defined in separate documents, then there may be more than 
one leaf document loaded although execution will only be in one of these documents. 

When a leaf document load causes a root document load, none of the dialogs in the root 
document are executed. Execution begins in the leaf document. 

There are several benefits to multi‐document applications. 

• The root document's variables are available for use by the leaf documents, so that 
information can be shared and retained. 
191 
 
 
• Root document <property> elements specify default values for properties used in the 
leaf documents. 
• Common ECMAScript code can be defined in root document <script> elements and used 
in the leaf documents. 
• Root document <catch> elements define default event handling for the leaf documents. 
• Document‐scoped grammars in the root document are active when the user is in a leaf 
document, so that the user is able to interact with forms, links, and menus in the root 
document. 

Here is a two‐document application illustrating this: 

Application root document (app‐root.vxml) 

<?xml version="1.0" encoding="UTF‐8"?> 
<vxml xmlns="http://www.w3.org/2001/vxml" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema‐instance"  
  xsi:schemaLocation="http://www.w3.org/2001/vxml  
   http://www.w3.org/TR/voicexml20/vxml.xsd" 
   version="2.0"> 
 <var name="bye" expr="'Ciao'"/> 
 <link next="operator_xfer.vxml"> 
   <grammar type="application/srgs+xml" root="root" version="1.0"> 
     <rule id="root" scope="public">operator</rule> 
  </grammar> 
 </link> 
</vxml> 

Leaf document (leaf.vxml) 

<?xml version="1.0" encoding="UTF‐8"?> 
<vxml xmlns="http://www.w3.org/2001/vxml"  
   xmlns:xsi="http://www.w3.org/2001/XMLSchema‐instance"  
   xsi:schemaLocation="http://www.w3.org/2001/vxml  
   http://www.w3.org/TR/voicexml20/vxml.xsd" 
   version="2.0" application="app‐root.vxml"> 
 <form id="say_goodbye"> 
  <field name="answer"> 
     <grammar type="application/srgs+xml" src="/grammars/boolean.grxml"/> 
     <prompt>Shall we say <value expr="application.bye"/>?</prompt> 
     <filled> 
       <if cond="answer"> 
        <exit/> 
       </if> 
       <clear namelist="answer"/> 
     </filled> 
  </field> 
192 
 
 
 </form> 
</vxml> 

In this example, the application is designed so that leaf.vxml must be loaded first. Its application 
attribute specifies that app‐root.vxml should be used as the application root document. So, 
app‐root.vxml is then loaded, which creates the application variable bye and also defines a link 
that navigates to operator‐xfer.vxml whenever the user says "operator". The user starts out in 
the say_goodbye form: 

C: Shall we say Ciao? 

H: Si. 

C: I did not understand what you said. (a platform‐specific default message.) 

C: Shall we say Ciao? 

H: Ciao 

C: I did not understand what you said. 

H: Operator. 

C: (Goes to operator_xfer.vxml, which transfers the caller to a human operator.) 

Note that when the user is in a multi‐document application, at most two documents are loaded 
at any one time: the application root document and, unless the user is actually interacting with 
the application root document, an application leaf document. A root document's <vxml> 
element does not have an application attribute specified. A leaf document's <vxml> element 
does have an application attribute specified. An interpreter always has an application root 
document loaded; it does not always have an application leaf document loaded. 

The name of the interpreter's current application is the application root document's absolute 
URI. The absolute URI includes a query string, if present, but it does not include a fragment 
identifier. The interpreter remains in the same application as long as the name remains the 
same. When the name changes, a new application is entered and its root context is initialized. 
The application's root context consists of the variables, grammars, catch elements, scripts, and 
properties in application scope. 

During a user session an interpreter transitions from one document to another as requested by 
<choice>, <goto> <link>, <subdialog>, and <submit> elements. Some transitions are within an 
application, others are between applications. The preservation or initialization of the root 
context depends on the type of transition: 

Root to Leaf Within Application 

193 
 
 
A root to leaf transition within the same application occurs when the current document 
is a root document and the target document's application attribute's value resolves to 
the same absolute URI as the name of the current application. The application root 
document and its context are preserved. 

Leaf to Leaf Within Application 

A leaf to leaf transition within the same application occurs when the current document 
is a leaf document and the target document's application attribute's value resolves to 
the same absolute URI as the name of the current application. The application root 
document and its context are preserved. 

Leaf to Root Within Application 

A leaf to root transition within the same application occurs when the current document 
is a leaf document and the target document's absolute URI is the same as the name of 
the current application. The current application root document and its context are 
preserved when the transition is caused by a <choice>, <goto>, or <link> element. The 
root context is initialized when a <submit> element causes the leaf to root transition, 
because a <submit> always results in a fetch of its URI. 

Root to Root 

A root to root transition occurs when the current document is a root document and the 
target document is a root document, i.e. it does not have an application attribute. The 
root context is initialized with the application root document returned by the caching 
policy in Section 6.1.2. The caching policy is consulted even when the name of the target 
application and the current application are the same. 

Subdialog 

A subdialog invocation occurs when a root or leaf document executes a <subdialog> 
element. As discussed in Section 2.3.4, subdialog invocation creates a new execution 
context. The application root document and its context in the calling document's 
execution context are preserved untouched during subdialog execution, and are used 
again once the subdialog returns. A subdialog's new execution context has its own root 
context and, possibly, leaf context. When the subdialog is invoked with a non‐empty URI 
reference, the caching policy in Section 6.1.2 is used to acquire the root and leaf 
documents that will be used to initialize the new root and leaf contexts. If a subdialog is 
invoked with an empty URI reference and a fragment identifier, e.g. "#sub1", the root 
and leaf documents remain unchanged, and therefore the current root and leaf 
documents will be used to initialize the new root and leaf contexts. 

Inter‐Application Transitions 
194 
 
 
All other transitions are between applications which cause the application root context 
to be initialized with the next application's root document. 

If a document refers to a non‐existent application root document, an error.badfetch event is 
thrown. If a document's application attribute refers to a document that also has an application 
attribute specified, an error.semantic event is thrown. 

The following diagrams illustrate the effect of the transitions between root and leaf documents 
on the application root context. In these diagrams, boxes represent documents, box texture 
changes identify root context initialization, solid arrows symbolize transitions to the URI in the 
arrow's label, dashed vertical arrows indicate an application attribute whose URI is the arrow's 
label. 

 
Figure 3: Transitions that Preserve the Root Context 

In this diagram, all the documents belong to the same application. The transitions are identified 
by the numbers 1‐4 across the top of the figure. They are: 

1. A transition to URI A results in document 1, the application context is initialized from 
document 1's content. Assume that this is the first document in the session. The current 
application's name is A. 
2. Document 1 specifies a transition to URI B, which yields document 2. Document 2's 
application attribute equals URI A. The root is document 1 with its context preserved. 
This is a root to leaf transition within the same application. 
3. Document 2 specifies a transition to URI C, which yields another leaf document, 
document 3. Its application attribute also equals URI A. The root is document 1 with its 
context preserved. This is a leaf to leaf transition within the same application. 
4. Document 3 specifies a transition to URI A using a <choice>, <goto>, or <link>. 
Document 1 is used with its root context intact. This is a leaf to root transition within the 
same application. 

The next diagram illustrates transitions which initialize the root context. 
195 
 
 

 
Figure 4: Transitions that Initialize the Root Context 

5. Document 1 specifies a transition to its own URI A. The resulting document 4 does not 
have an application attribute, so it is considered a root document, and the root context 
is initialized. This is a root to root transition. 
6. Document 4 specifies a transition to URI D, which yields a leaf document 5. Its 
application attribute is different: URI E. A new application is being entered. URI E 
produces the root document 6. The root context is initialized from the content of 
document 6. This is an inter‐application transition. 
7. Document 5 specifies a transition to URI A. The cache check returns document 4 which 
does not have an application attribute and therefore belongs to application A, so the 
root context is initialized. Initialization occurs even though this application and this root 
document were used earlier in the session. This is an inter‐application transition. 

1.5.3 Subdialogs 

A subdialog is a mechanism for decomposing complex sequences of dialogs to better structure 
them, or to create reusable components. For example, the solicitation of account information 
may involve gathering several pieces of information, such as account number, and home 
telephone number. A customer care service might be structured with several independent 
applications that could share this basic building block, thus it would be reasonable to construct 
it as a subdialog. This is illustrated in the example below. The first document, app.vxml, seeks to 
adjust a customer's account, and in doing so must get the account information and then the 
adjustment level. The account information is obtained by using a subdialog element that 
invokes another VoiceXML document to solicit the user input. While the second document is 
being executed, the calling dialog is suspended, awaiting the return of information. The second 
document provides the results of its user interactions using a <return> element, and the 
resulting values are accessed through the variable defined by the name attribute on the 
<subdialog> element. 

Customer Service Application (app.vxml) 

<?xml version="1.0" encoding="UTF‐8"?> 
196 
 
 
<vxml xmlns="http://www.w3.org/2001/vxml"  
   xmlns:xsi="http://www.w3.org/2001/XMLSchema‐instance"  
   xsi:schemaLocation="http://www.w3.org/2001/vxml  
   http://www.w3.org/TR/voicexml20/vxml.xsd" 
   version="2.0"> 
  <form id="billing_adjustment"> 
    <var name="account_number"/> 
    <var name="home_phone"/> 
    <subdialog name="accountinfo" src="acct_info.vxml#basic"> 
      <filled> 
        <!‐‐ Note the variable defined by "accountinfo" is 
          returned as an ECMAScript object and it contains two 
          properties defined by the variables specified in the 
          "return" element of the subdialog. ‐‐> 
 
        <assign name="account_number" expr="accountinfo.acctnum"/> 
        <assign name="home_phone" expr="accountinfo.acctphone"/> 
      </filled> 
    </subdialog> 
 
    <field name="adjustment_amount"> 
     <grammar type="application/srgs+xml" src="/grammars/currency.grxml"/> 
      <prompt> 
        What is the value of your account adjustment? 
      </prompt> 
      <filled> 
        <submit  next="/cgi‐bin/updateaccount"/> 
      </filled> 
    </field> 
  </form> 
</vxml> 

Document Containing Account Information Subdialog (acct_info.vxml) 

<?xml version="1.0" encoding="UTF‐8"?> 
<vxml xmlns="http://www.w3.org/2001/vxml" 
  xmlns:xsi="http://www.w3.org/2001/XMLSchema‐instance"  
   xsi:schemaLocation="http://www.w3.org/2001/vxml  
   http://www.w3.org/TR/voicexml20/vxml.xsd" 
   version="2.0"> 
  <form id="basic"> 
    <field name="acctnum"> 
      <grammar type="application/srgs+xml" src="/grammars/digits.grxml"/> 
      <prompt> What is your account number? </prompt> 
    </field> 
    <field name="acctphone"> 
197 
 
 
      <grammar type="application/srgs+xml" src="/grammars/phone_numbers.grxml"/> 
      <prompt> What is your home telephone number? </prompt> 
      <filled> 
        <!‐‐ The values obtained by the two fields are supplied 
          to the calling dialog by the "return" element. ‐‐> 
        <return namelist="acctnum acctphone"/> 
      </filled> 
    </field> 
  </form> 
</vxml> 

Subdialogs add a new execution context when they are invoked.The subdialog could be a new 
dialog within the existing document, or a new dialog within a new document. 

Subdialogs can be composed of several documents. Figure 5 shows the execution flow where a 
sequence of documents (D) transitions to a subdialog (SD) and then back. 

 
Figure 5: Subdialog composed of several documents 
returning from the last subdialog document. 

The execution context in dialog D2 is suspended when it invokes the subdialog SD1 in document 
sd1.vxml. This subdialog specifies execution is to be transfered to the dialog in sd2.vxml (using 
<goto>). Consequently, when the dialog in sd2.vxml returns, control is returned directly to 
dialog D2. 

Figure 6 shows an example of a multi‐document subdialog where control is transferred from 
one subdialog to another. 
198 
 
 

 
Figure 6: Subdialog composed of several documents 
returning from the first subdialog document. 

The subdialog in sd1.vxml specifies that control is to be transfered to a second subdialog, SD2, 
in sd2.vxml. When executing SD2, there are two suspended contexts: the dialog context in D2 is 
suspending awaiting SD1 to return; and the dialog context in SD1 awaiting SD2 to return. When 
SD2 returns, control is returned to the SD1. It in turn returns control to dialog D2. 

1.5.4 Final Processing 

Under certain circumstances (in particular, while the VoiceXML interpreter is processing a 
disconnect event) the interpreter may continue executing in the final processing state after 
there is no longer a connection to allow the interpreter to interact with the end user. The 
purpose of this state is to allow the VoiceXML application to perform any necessary final 
cleanup, such as submitting information to the application server. For example, the following 
<catch> element will catch the connection.disconnect.hangup event and execute in the final 
processing state: 

<catch event="connection.disconnect.hangup"> 
    <submit namelist="myExit" next="http://mysite/exit.jsp"/> 
</catch> 

While in the final processing state the application must remain in the transitioning state and 
may not enter the waiting state (as described in Section 4.1.8). Thus for example the application 
should not enter <field>, <record>, or <transfer> while in the final processing state. The 
VoiceXML interpreter must exit if the VoiceXML application attempts to enter the waiting state 
while in the final processing state. 

199 
 
 
Aside from this restriction, execution of the VoiceXML application continues normally while in 
the final processing state. Thus for example the application may transition between documents 
while in the final processing state, and the interpreter must exit if no form item is eligible to be 
selected (as described in Section 2.1.1). 

1 Introduction 

This specification defines the syntax and semantics of the XSLT language. A transformation in 
the XSLT language is expressed as a well‐formed XML document [XML] conforming to the 
Namespaces in XML Recommendation [XML Names], which may include both elements that are 
defined by XSLT and elements that are not defined by XSLT. XSLT‐defined elements are 
distinguished by belonging to a specific XML namespace (see [2.1 XSLT Namespace]), which is 
referred to in this specification as the XSLT namespace. Thus this specification is a definition of 
the syntax and semantics of the XSLT namespace. 

A transformation expressed in XSLT describes rules for transforming a source tree into a result 
tree. The transformation is achieved by associating patterns with templates. A pattern is 
matched against elements in the source tree. A template is instantiated to create part of the 
result tree. The result tree is separate from the source tree. The structure of the result tree can 
be completely different from the structure of the source tree. In constructing the result tree, 
elements from the source tree can be filtered and reordered, and arbitrary structure can be 
added. 

A transformation expressed in XSLT is called a stylesheet. This is because, in the case when XSLT 
is transforming into the XSL formatting vocabulary, the transformation functions as a 
stylesheet. 

This document does not specify how an XSLT stylesheet is associated with an XML document. It 
is recommended that XSL processors support the mechanism described in [XML Stylesheet]. 
When this or any other mechanism yields a sequence of more than one XSLT stylesheet to be 
applied simultaneously to a XML document, then the effect should be the same as applying a 
single stylesheet that imports each member of the sequence in order (see [2.6.2 Stylesheet 
Import]). 

A stylesheet contains a set of template rules. A template rule has two parts: a pattern which is 
matched against nodes in the source tree and a template which can be instantiated to form 
part of the result tree. This allows a stylesheet to be applicable to a wide class of documents 
that have similar source tree structures. 

A template is instantiated for a particular source element to create part of the result tree. A 
template can contain elements that specify literal result element structure. A template can also 
contain elements from the XSLT namespace that are instructions for creating result tree 
fragments. When a template is instantiated, each instruction is executed and replaced by the 
result tree fragment that it creates. Instructions can select and process descendant source 
elements. Processing a descendant element creates a result tree fragment by finding the 
applicable template rule and instantiating its template. Note that elements are only processed 
200 
 
 
when they have been selected by the execution of an instruction. The result tree is constructed 
by finding the template rule for the root node and instantiating its template. 

In the process of finding the applicable template rule, more than one template rule may have a 
pattern that matches a given element. However, only one template rule will be applied. The 
method for deciding which template rule to apply is described in [5.5 Conflict Resolution for 
Template Rules]. 

A single template by itself has considerable power: it can create structures of arbitrary 
complexity; it can pull string values out of arbitrary locations in the source tree; it can generate 
structures that are repeated according to the occurrence of elements in the source tree. For 
simple transformations where the structure of the result tree is independent of the structure of 
the source tree, a stylesheet can often consist of only a single template, which functions as a 
template for the complete result tree. Transformations on XML documents that represent data 
are often of this kind (see [D.2 Data Example]). XSLT allows a simplified syntax for such 
stylesheets (see [2.3 Literal Result Element as Stylesheet]). 

When a template is instantiated, it is always instantiated with respect to a current node and a 
current node list. The current node is always a member of the current node list. Many 
operations in XSLT are relative to the current node. Only a few instructions change the current 
node list or the current node (see [5 Template Rules] and [8 Repetition]); during the 
instantiation of one of these instructions, the current node list changes to a new list of nodes 
and each member of this new list becomes the current node in turn; after the instantiation of 
the instruction is complete, the current node and current node list revert to what they were 
before the instruction was instantiated. 

XSLT makes use of the expression language defined by [XPath] for selecting elements for 
processing, for conditional processing and for generating text. 

XSLT provides two "hooks" for extending the language, one hook for extending the set of 
instruction elements used in templates and one hook for extending the set of functions used in 
XPath expressions. These hooks are both based on XML namespaces. This version of XSLT does 
not define a mechanism for implementing the hooks. See [14 Extensions]. 

NOTE:The XSL WG intends to define such a mechanism in a future version of this specification 
or in a separate specification. 

The element syntax summary notation used to describe the syntax of XSLT‐defined elements is 
described in [18 Notation]. 

The MIME media types text/xml and application/xml [RFC2376] should be used for XSLT 
stylesheets. It is possible that a media type will be registered specifically for XSLT stylesheets; if 
and when it is, that media type may also be used. 

201 
 
 
2 Stylesheet Structure 

2.1 XSLT Namespace 

The XSLT namespace has the URI http://www.w3.org/1999/XSL/Transform. 

NOTE:The 1999 in the URI indicates the year in which the URI was allocated by the W3C. It does 
not indicate the version of XSLT being used, which is specified by attributes (see [2.2 Stylesheet 
Element] and [2.3 Literal Result Element as Stylesheet]). 

XSLT processors must use the XML namespaces mechanism [XML Names] to recognize 
elements and attributes from this namespace. Elements from the XSLT namespace are 
recognized only in the stylesheet not in the source document. The complete list of XSLT‐defined 
elements is specified in [B Element Syntax Summary]. Vendors must not extend the XSLT 
namespace with additional elements or attributes. Instead, any extension must be in a separate 
namespace. Any namespace that is used for additional instruction elements must be identified 
by means of the extension element mechanism specified in [14.1 Extension Elements]. 

This specification uses a prefix of xsl: for referring to elements in the XSLT namespace. 
However, XSLT stylesheets are free to use any prefix, provided that there is a namespace 
declaration that binds the prefix to the URI of the XSLT namespace. 

An element from the XSLT namespace may have any attribute not from the XSLT namespace, 
provided that the expanded‐name of the attribute has a non‐null namespace URI. The presence 
of such attributes must not change the behavior of XSLT elements and functions defined in this 
document. Thus, an XSLT processor is always free to ignore such attributes, and must ignore 
such attributes without giving an error if it does not recognize the namespace URI. Such 
attributes can provide, for example, unique identifiers, optimization hints, or documentation. 

It is an error for an element from the XSLT namespace to have attributes with expanded‐names 
that have null namespace URIs (i.e. attributes with unprefixed names) other than attributes 
defined for the element in this document. 

NOTE:The conventions used for the names of XSLT elements, attributes and functions are that 
names are all lower‐case, use hyphens to separate words, and use abbreviations only if they 
already appear in the syntax of a related language such as XML or HTML. 

2.2 Stylesheet Element 

<xsl:stylesheet 
  id = id  
  extension‐element‐prefixes = tokens  
  exclude‐result‐prefixes = tokens  
  version = number> 
  <!‐‐ Content: (xsl:import*, top‐level‐elements) ‐‐> 
</xsl:stylesheet> 
202 
 
 
<xsl:transform 
  id = id  
  extension‐element‐prefixes = tokens  
  exclude‐result‐prefixes = tokens  
  version = number> 
  <!‐‐ Content: (xsl:import*, top‐level‐elements) ‐‐> 
</xsl:transform> 

A stylesheet is represented by an xsl:stylesheet element in an XML document. xsl:transform is 
allowed as a synonym for xsl:stylesheet. 

An xsl:stylesheet element must have a version attribute, indicating the version of XSLT that the 
stylesheet requires. For this version of XSLT, the value should be 1.0. When the value is not 
equal to 1.0, forwards‐compatible processing mode is enabled (see [2.5 Forwards‐Compatible 
Processing]). 

The xsl:stylesheet element may contain the following types of elements: 

• xsl:import 
• xsl:include 
• xsl:strip‐space 
• xsl:preserve‐space 
• xsl:output 
• xsl:key 
• xsl:decimal‐format 
• xsl:namespace‐alias 
• xsl:attribute‐set 
• xsl:variable 
• xsl:param 
• xsl:template 

An element occurring as a child of an xsl:stylesheet element is called a top‐level element. 

This example shows the structure of a stylesheet. Ellipses (...) indicate where attribute values or 
content have been omitted. Although this example shows one of each type of allowed element, 
stylesheets may contain zero or more of each of these elements. 

<xsl:stylesheet version="1.0" 
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> 
  <xsl:import href="..."/> 
 
  <xsl:include href="..."/> 
 
  <xsl:strip‐space elements="..."/> 
   
  <xsl:preserve‐space elements="..."/> 

203 
 
 
 
  <xsl:output method="..."/> 
 
  <xsl:key name="..." match="..." use="..."/> 
 
  <xsl:decimal‐format name="..."/> 
 
  <xsl:namespace‐alias stylesheet‐prefix="..." result‐prefix="..."/> 
 
  <xsl:attribute‐set name="..."> 
    ... 
  </xsl:attribute‐set> 
 
  <xsl:variable name="...">...</xsl:variable> 
 
  <xsl:param name="...">...</xsl:param> 
 
  <xsl:template match="..."> 
    ... 
  </xsl:template> 
 
  <xsl:template name="..."> 
    ... 
  </xsl:template> 
 
</xsl:stylesheet> 

The order in which the children of the xsl:stylesheet element occur is not significant except for 
xsl:import elements and for error recovery. Users are free to order the elements as they prefer, 
and stylesheet creation tools need not provide control over the order in which the elements 
occur. 

In addition, the xsl:stylesheet element may contain any element not from the XSLT namespace, 
provided that the expanded‐name of the element has a non‐null namespace URI. The presence 
of such top‐level elements must not change the behavior of XSLT elements and functions 
defined in this document; for example, it would not be permitted for such a top‐level element 
to specify that xsl:apply‐templates was to use different rules to resolve conflicts. Thus, an XSLT 
processor is always free to ignore such top‐level elements, and must ignore a top‐level element 
without giving an error if it does not recognize the namespace URI. Such elements can provide, 
for example, 

• information used by extension elements or extension functions (see [14 Extensions]), 
• information about what to do with the result tree, 
• information about how to obtain the source tree, 
• metadata about the stylesheet, 
• structured documentation for the stylesheet. 
204 
 
 
2.3 Literal Result Element as Stylesheet 

A simplified syntax is allowed for stylesheets that consist of only a single template for the root 
node. The stylesheet may consist of just a literal result element (see [7.1.1 Literal Result 
Elements]). Such a stylesheet is equivalent to a stylesheet with an xsl:stylesheet element 
containing a template rule containing the literal result element; the template rule has a match 
pattern of /. For example 

<html xsl:version="1.0" 
      xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
      xmlns="http://www.w3.org/TR/xhtml1/strict"> 
  <head> 
    <title>Expense Report Summary</title> 
  </head> 
  <body> 
    <p>Total Amount: <xsl:value‐of select="expense‐report/total"/></p> 
  </body> 
</html> 

has the same meaning as 

<xsl:stylesheet version="1.0" 
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
                xmlns="http://www.w3.org/TR/xhtml1/strict"> 
<xsl:template match="/"> 
<html> 
  <head> 
    <title>Expense Report Summary</title> 
  </head> 
  <body> 
    <p>Total Amount: <xsl:value‐of select="expense‐report/total"/></p> 
  </body> 
</html> 
</xsl:template> 
</xsl:stylesheet> 

A literal result element that is the document element of a stylesheet must have an xsl:version 
attribute, which indicates the version of XSLT that the stylesheet requires. For this version of 
XSLT, the value should be 1.0; the value must be a Number. Other literal result elements may 
also have an xsl:version attribute. When the xsl:version attribute is not equal to 1.0, forwards‐
compatible processing mode is enabled (see [2.5 Forwards‐Compatible Processing]). 

The allowed content of a literal result element when used as a stylesheet is no different from 
when it occurs within a stylesheet. Thus, a literal result element used as a stylesheet cannot 
contain top‐level elements. 

205 
 
 
In some situations, the only way that a system can recognize that an XML document needs to 
be processed by an XSLT processor as an XSLT stylesheet is by examining the XML document 
itself. Using the simplified syntax makes this harder. 

NOTE:For example, another XML language (AXL) might also use an axl:version on the document 
element to indicate that an XML document was an AXL document that required processing by 
an AXL processor; if a document had both an axl:version attribute and an xsl:version attribute, 
it would be unclear whether the document should be processed by an XSLT processor or an AXL 
processor. 

Therefore, the simplified syntax should not be used for XSLT stylesheets that may be used in 
such a situation. This situation can, for example, arise when an XSLT stylesheet is transmitted as 
a message with a MIME media type of text/xml or application/xml to a recipient that will use 
the MIME media type to determine how the message is processed. 

2.4 Qualified Names 

The name of an internal XSLT object, specifically a named template (see [6 Named Templates]), 
a mode (see [5.7 Modes]), an attribute set (see [7.1.4 Named Attribute Sets]), a key (see [12.2 
Keys]), a decimal‐format (see [12.3 Number Formatting]), a variable or a parameter (see [11 
Variables and Parameters]) is specified as a QName. If it has a prefix, then the prefix is 
expanded into a URI reference using the namespace declarations in effect on the attribute in 
which the name occurs. The expanded‐name consisting of the local part of the name and the 
possibly null URI reference is used as the name of the object. The default namespace is not 
used for unprefixed names. 

2.5 Forwards‐Compatible Processing 

An element enables forwards‐compatible mode for itself, its attributes, its descendants and 
their attributes if either it is an xsl:stylesheet element whose version attribute is not equal to 
1.0, or it is a literal result element that has an xsl:version attribute whose value is not equal to 
1.0, or it is a literal result element that does not have an xsl:version attribute and that is the 
document element of a stylesheet using the simplified syntax (see [2.3 Literal Result Element 
as Stylesheet]). A literal result element that has an xsl:version attribute whose value is equal to 
1.0 disables forwards‐compatible mode for itself, its attributes, its descendants and their 
attributes. 

If an element is processed in forwards‐compatible mode, then: 

• if it is a top‐level element and XSLT 1.0 does not allow such elements as top‐level 
elements, then the element must be ignored along with its content; 
• if it is an element in a template and XSLT 1.0 does not allow such elements to occur in 
templates, then if the element is not instantiated, an error must not be signaled, and if 
the element is instantiated, the XSLT must perform fallback for the element as specified 
in [15 Fallback]; 
206 
 
 
• if the element has an attribute that XSLT 1.0 does not allow the element to have or if 
the element has an optional attribute with a value that the XSLT 1.0 does not allow the 
attribute to have, then the attribute must be ignored. 

Thus, any XSLT 1.0 processor must be able to process the following stylesheet without error, 
although the stylesheet includes elements from the XSLT namespace that are not defined in this 
specification: 

<xsl:stylesheet version="1.1" 
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> 
  <xsl:template match="/"> 
    <xsl:choose> 
      <xsl:when test="system‐property('xsl:version') >= 1.1"> 
        <xsl:exciting‐new‐1.1‐feature/> 
      </xsl:when> 
      <xsl:otherwise> 
        <html> 
        <head> 
          <title>XSLT 1.1 required</title> 
        </head> 
        <body> 
          <p>Sorry, this stylesheet requires XSLT 1.1.</p> 
        </body> 
        </html> 
      </xsl:otherwise> 
    </xsl:choose> 
  </xsl:template> 
</xsl:stylesheet> 
NOTE:If a stylesheet depends crucially on a top‐level element introduced by a version of XSL 
after 1.0, then the stylesheet can use an xsl:message element with terminate="yes" (see [13 
Messages]) to ensure that XSLT processors implementing earlier versions of XSL will not silently 
ignore the top‐level element. For example,  

<xsl:stylesheet version="1.5" 
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> 
 
  <xsl:important‐new‐1.1‐declaration/> 
 
  <xsl:template match="/"> 
    <xsl:choose> 
      <xsl:when test="system‐property('xsl:version') &lt; 1.1"> 
        <xsl:message terminate="yes"> 
          <xsl:text>Sorry, this stylesheet requires XSLT 1.1.</xsl:text> 
        </xsl:message> 
      </xsl:when> 
      <xsl:otherwise> 
207 
 
 
        ... 
      </xsl:otherwise> 
    </xsl:choose> 
  </xsl:template> 
  ... 
</xsl:stylesheet> 

If an expression occurs in an attribute that is processed in forwards‐compatible mode, then an 
XSLT processor must recover from errors in the expression as follows: 

• if the expression does not match the syntax allowed by the XPath grammar, then an 
error must not be signaled unless the expression is actually evaluated; 
• if the expression calls a function with an unprefixed name that is not part of the XSLT 
library, then an error must not be signaled unless the function is actually called; 
• if the expression calls a function with a number of arguments that XSLT does not allow 
or with arguments of types that XSLT does not allow, then an error must not be signaled 
unless the function is actually called. 

2.6 Combining Stylesheets 

XSLT provides two mechanisms to combine stylesheets: 

• an inclusion mechanism that allows stylesheets to be combined without changing the 
semantics of the stylesheets being combined, and 
• an import mechanism that allows stylesheets to override each other. 

2.6.1 Stylesheet Inclusion 

<!‐‐ Category: top‐level‐element ‐‐> 
<xsl:include 
  href = uri‐reference /> 

An XSLT stylesheet may include another XSLT stylesheet using an xsl:include element. The 
xsl:include element has an href attribute whose value is a URI reference identifying the 
stylesheet to be included. A relative URI is resolved relative to the base URI of the xsl:include 
element (see [3.2 Base URI]). 

The xsl:include element is only allowed as a top‐level element. 

The inclusion works at the XML tree level. The resource located by the href attribute value is 
parsed as an XML document, and the children of the xsl:stylesheet element in this document 
replace the xsl:include element in the including document. The fact that template rules or 
definitions are included does not affect the way they are processed. 

208 
 
 
The included stylesheet may use the simplified syntax described in [2.3 Literal Result Element 
as Stylesheet]. The included stylesheet is treated the same as the equivalent xsl:stylesheet 
element. 

It is an error if a stylesheet directly or indirectly includes itself. 

NOTE:Including a stylesheet multiple times can cause errors because of duplicate definitions. 
Such multiple inclusions are less obvious when they are indirect. For example, if stylesheet B 
includes stylesheet A, stylesheet C includes stylesheet A, and stylesheet D includes both 
stylesheet B and stylesheet C, then A will be included indirectly by D twice. If all of B, C and D 
are used as independent stylesheets, then the error can be avoided by separating everything in 
B other than the inclusion of A into a separate stylesheet B' and changing B to contain just 
inclusions of B' and A, similarly for C, and then changing D to include A, B', C'. 

2.6.2 Stylesheet Import 

<xsl:import 
  href = uri‐reference /> 

An XSLT stylesheet may import another XSLT stylesheet using an xsl:import element. Importing 
a stylesheet is the same as including it (see [2.6.1 Stylesheet Inclusion]) except that definitions 
and template rules in the importing stylesheet take precedence over template rules and 
definitions in the imported stylesheet; this is described in more detail below. The xsl:import 
element has an href attribute whose value is a URI reference identifying the stylesheet to be 
imported. A relative URI is resolved relative to the base URI of the xsl:import element (see [3.2 
Base URI]). 

The xsl:import element is only allowed as a top‐level element. The xsl:import element children 
must precede all other element children of an xsl:stylesheet element, including any xsl:include 
element children. When xsl:include is used to include a stylesheet, any xsl:import elements in 
the included document are moved up in the including document to after any existing xsl:import 
elements in the including document. 

For example, 

<xsl:stylesheet version="1.0" 
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> 
  <xsl:import href="article.xsl"/> 
  <xsl:import href="bigfont.xsl"/> 
  <xsl:attribute‐set name="note‐style"> 
    <xsl:attribute name="font‐style">italic</xsl:attribute> 
  </xsl:attribute‐set> 
</xsl:stylesheet> 

209 
 
 
The xsl:stylesheet elements encountered during processing of a stylesheet that contains 
xsl:import elements are treated as forming an import tree. In the import tree, each 
xsl:stylesheet element has one import child for each xsl:import element that it contains. Any 
xsl:include elements are resolved before constructing the import tree. An xsl:stylesheet 
element in the import tree is defined to have lower import precedence than another 
xsl:stylesheet element in the import tree if it would be visited before that xsl:stylesheet 
element in a post‐order traversal of the import tree (i.e. a traversal of the import tree in which 
an xsl:stylesheet element is visited after its import children). Each definition and template rule 
has import precedence determined by the xsl:stylesheet element that contains it. 

For example, suppose 

• stylesheet A imports stylesheets B and C in that order; 
• stylesheet B imports stylesheet D; 
• stylesheet C imports stylesheet E. 

Then the order of import precedence (lowest first) is D, B, E, C, A. 

NOTE:Since xsl:import elements are required to occur before any definitions or template rules, 
an implementation that processes imported stylesheets at the point at which it encounters the 
xsl:import element will encounter definitions and template rules in increasing order of import 
precedence. 

In general, a definition or template rule with higher import precedence takes precedence over a 
definition or template rule with lower import precedence. This is defined in detail for each kind 
of definition and for template rules. 

It is an error if a stylesheet directly or indirectly imports itself. Apart from this, the case where a 
stylesheet with a particular URI is imported in multiple places is not treated specially. The 
import tree will have a separate xsl:stylesheet for each place that it is imported. 

NOTE:If xsl:apply‐imports is used (see [5.6 Overriding Template Rules]), the behavior may be 
different from the behavior if the stylesheet had been imported only at the place with the 
highest import precedence. 

2.7 Embedding Stylesheets 

Normally an XSLT stylesheet is a complete XML document with the xsl:stylesheet element as 
the document element. However, an XSLT stylesheet may also be embedded in another 
resource. Two forms of embedding are possible: 

• the XSLT stylesheet may be textually embedded in a non‐XML resource, or 
• the xsl:stylesheet element may occur in an XML document other than as the document 
element. 

210 
 
 
To facilitate the second form of embedding, the xsl:stylesheet element is allowed to have an ID 
attribute that specifies a unique identifier. 

NOTE:In order for such an attribute to be used with the XPath id function, it must actually be 
declared in the DTD as being an ID. 

The following example shows how the xml‐stylesheet processing instruction [XML Stylesheet] 
can be used to allow a document to contain its own stylesheet. The URI reference uses a 
relative URI with a fragment identifier to locate the xsl:stylesheet element: 

<?xml‐stylesheet type="text/xml" href="#style1"?> 
<!DOCTYPE doc SYSTEM "doc.dtd"> 
<doc> 
<head> 
<xsl:stylesheet id="style1" 
                version="1.0" 
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform" 
                xmlns:fo="http://www.w3.org/1999/XSL/Format"> 
<xsl:import href="doc.xsl"/> 
<xsl:template match="id('foo')"> 
  <fo:block font‐weight="bold"><xsl:apply‐templates/></fo:block> 
</xsl:template> 
<xsl:template match="xsl:stylesheet"> 
  <!‐‐ ignore ‐‐> 
</xsl:template> 
</xsl:stylesheet> 
</head> 
<body> 
<para id="foo"> 
... 
</para> 
</body> 
</doc> 
NOTE:A stylesheet that is embedded in the document to which it is to be applied or that may 
be included or imported into an stylesheet that is so embedded typically needs to contain a 
template rule that specifies that xsl:stylesheet elements are to be ignored. 

3 Data Model 

The data model used by XSLT is the same as that used by XPath with the additions described in 
this section. XSLT operates on source, result and stylesheet documents using the same data 
model. Any two XML documents that have the same tree will be treated the same by XSLT. 

Processing instructions and comments in the stylesheet are ignored: the stylesheet is treated as 
if neither processing instruction nodes nor comment nodes were included in the tree that 
represents the stylesheet. 
211 
 
 
3.1 Root Node Children 

The normal restrictions on the children of the root node are relaxed for the result tree. The 
result tree may have any sequence of nodes as children that would be possible for an element 
node. In particular, it may have text node children, and any number of element node children. 
When written out using the XML output method (see [16 Output]), it is possible that a result 
tree will not be a well‐formed XML document; however, it will always be a well‐formed external 
general parsed entity. 

When the source tree is created by parsing a well‐formed XML document, the root node of the 
source tree will automatically satisfy the normal restrictions of having no text node children and 
exactly one element child. When the source tree is created in some other way, for example by 
using the DOM, the usual restrictions are relaxed for the source tree as for the result tree. 

3.2 Base URI 

Every node also has an associated URI called its base URI, which is used for resolving attribute 
values that represent relative URIs into absolute URIs. If an element or processing instruction 
occurs in an external entity, the base URI of that element or processing instruction is the URI of 
the external entity; otherwise, the base URI is the base URI of the document. The base URI of 
the document node is the URI of the document entity. The base URI for a text node, a comment 
node, an attribute node or a namespace node is the base URI of the parent of the node. 

3.3 Unparsed Entities 

The root node has a mapping that gives the URI for each unparsed entity declared in the 
document's DTD. The URI is generated from the system identifier and public identifier specified 
in the entity declaration. The XSLT processor may use the public identifier to generate a URI for 
the entity instead of the URI specified in the system identifier. If the XSLT processor does not 
use the public identifier to generate the URI, it must use the system identifier; if the system 
identifier is a relative URI, it must be resolved into an absolute URI using the URI of the 
resource containing the entity declaration as the base URI [RFC2396]. 

3.4 Whitespace Stripping 

After the tree for a source document or stylesheet document has been constructed, but before 
it is otherwise processed by XSLT, some text nodes are stripped. A text node is never stripped 
unless it contains only whitespace characters. Stripping the text node removes the text node 
from the tree. The stripping process takes as input a set of element names for which 
whitespace must be preserved. The stripping process is applied to both stylesheets and source 
documents, but the set of whitespace‐preserving element names is determined differently for 
stylesheets and for source documents. 

A text node is preserved if any of the following apply: 

212 
 
 
• The element name of the parent of the text node is in the set of whitespace‐preserving 
element names. 
• The text node contains at least one non‐whitespace character. As in XML, a whitespace 
character is #x20, #x9, #xD or #xA. 
• An ancestor element of the text node has an xml:space attribute with a value of 
preserve, and no closer ancestor element has xml:space with a value of default. 

Otherwise, the text node is stripped. 

The xml:space attributes are not stripped from the tree. 

NOTE:This implies that if an xml:space attribute is specified on a literal result element, it will be 
included in the result. 

For stylesheets, the set of whitespace‐preserving element names consists of just xsl:text. 

<!‐‐ Category: top‐level‐element ‐‐> 
<xsl:strip‐space 
  elements = tokens /> 

<!‐‐ Category: top‐level‐element ‐‐> 
<xsl:preserve‐space 
  elements = tokens /> 

For source documents, the set of whitespace‐preserving element names is specified by xsl:strip‐
space and xsl:preserve‐space top‐level elements. These elements each have an elements 
attribute whose value is a whitespace‐separated list of NameTests. Initially, the set of 
whitespace‐preserving element names contains all element names. If an element name 
matches a NameTest in an xsl:strip‐space element, then it is removed from the set of 
whitespace‐preserving element names. If an element name matches a NameTest in an 
xsl:preserve‐space element, then it is added to the set of whitespace‐preserving element 
names. An element matches a NameTest if and only if the NameTest would be true for the 
element as an XPath node test. Conflicts between matches to xsl:strip‐space and xsl:preserve‐
space elements are resolved the same way as conflicts between template rules (see [5.5 
Conflict Resolution for Template Rules]). Thus, the applicable match for a particular element 
name is determined as follows: 

• First, any match with lower import precedence than another match is ignored. 
• Next, any match with a NameTest that has a lower default priority than the default 
priority of the NameTest of another match is ignored. 

It is an error if this leaves more than one match. An XSLT processor may signal the error; if it 
does not signal the error, it must recover by choosing, from amongst the matches that are left, 
the one that occurs last in the stylesheet. 

213 
 
 
4 Expressions 

XSLT uses the expression language defined by XPath [XPath]. Expressions are used in XSLT for a 
variety of purposes including: 

• selecting nodes for processing; 
• specifying conditions for different ways of processing a node; 
• generating text to be inserted in the result tree. 

An expression must match the XPath production Expr. 

Expressions occur as the value of certain attributes on XSLT‐defined elements and within curly 
braces in attribute value templates. 

In XSLT, an outermost expression (i.e. an expression that is not part of another expression) gets 
its context as follows: 

• the context node comes from the current node 
• the context position comes from the position of the current node in the current node 
list; the first position is 1 
• the context size comes from the size of the current node list 
• the variable bindings are the bindings in scope on the element which has the attribute in 
which the expression occurs (see [11 Variables and Parameters]) 
• the set of namespace declarations are those in scope on the element which has the 
attribute in which the expression occurs; this includes the implicit declaration of the 
prefix xml required by the the XML Namespaces Recommendation [XML Names]; the 
default namespace (as declared by xmlns) is not part of this set 
• the function library consists of the core function library together with the additional 
functions defined in [12 Additional Functions] and extension functions as described in 
[14 Extensions]; it is an error for an expression to include a call to any other function 

1 Introduction 

This specification defines the XML Linking Language (XLink), which allows elements to be 
inserted into XML documents in order to create and describe links between resources. 

XLink provides a framework for creating both basic unidirectional links and more complex 
linking structures. It allows XML documents to: 

• Assert linking relationships among more than two resources 
• Associate metadata with a link 
• Express links that reside in a location separate from the linked resources 

An important application of XLink is in hypermedia systems that have hyperlinks. A simple case 
of a hyperlink is an HTML A element, which has these characteristics: 

214 
 
 
• The hyperlink uses URIs as its locator technology. 
• The hyperlink is expressed at one of its two ends. 
• The hyperlink identifies the other end (although a server may have great freedom in 
finding or dynamically creating that destination). 
• Users can initiate traversal only from the end where the hyperlink is expressed to the 
other end. 
• The hyperlink's effect on windows, frames, go‐back lists, style sheets in use, and so on is 
determined by user agents, not by the hyperlink itself. For example, traversal of A links 
normally replaces the current view, perhaps with a user option to open a new window. 

This set of characteristics is powerful, but the model that underlies them limits the range of 
possible hyperlink functionality. The model defined in this specification shares with HTML the 
use of URI technology, but goes beyond HTML in offering features, previously available only in 
dedicated hypermedia systems, that make hyperlinking more scalable and flexible. Along with 
providing linking data structures, XLink provides a minimal link behavior model; higher‐level 
applications layered on XLink will often specify alternate or more sophisticated rendering and 
processing treatments. 

Integrated treatment of specialized links used in other technical domains, such as foreign keys 
in relational databases and reference values in programming languages, is outside the scope of 
this specification. 

1.1 Origin and Goals 

The design of XLink has been informed by knowledge of established hypermedia systems and 
standards. The following standards have been especially influential: 

• HTML [HTML]: Defines several element types that represent links. 
• HyTime [ISO/IEC 10744]: Defines inline and inbound and third‐party link structures and 
some semantic features, including traversal control and presentation of objects. 
• Text Encoding Initiative Guidelines [TEI]: Provides structures for creating links, aggregate 
objects, and link collections. 

Many other linking systems have also informed the design of XLink, especially [Dexter], [FRESS], 
[OHS], [MicroCosm], and [Intermedia]. 

See the XLink Requirements Document [XLREQ] for a thorough explanation of requirements for 
the design of XLink. 

2 XLink Concepts 

This section describes the terms and concepts that are essential to understanding XLink, 
without discussing the syntax used to create XLink constructs. A few additional terms are 
introduced in later parts of this specification. 

215 
 
 
2.1 Links and Resources 

[Definition: An XLink link is an explicit relationship between resources or portions of resources.] 
[Definition: It is made explicit by an XLink linking element, which is an XLink‐conforming XML 
element that asserts the existence of a link.] There are six XLink elements; only two of them are 
considered linking elements. The others provide various pieces of information that describe the 
characteristics of a link. (The term "link" as used in this specification refers only to an XLink link, 
though nothing prevents non‐XLink constructs from serving as links.) 

The notion of resources is universal to the World Wide Web. [Definition: As discussed in [IETF 
RFC 2396], a resource is any addressable unit of information or service.] Examples include files, 
images, documents, programs, and query results. The means used for addressing a resource is a 
URI (Uniform Resource Identifier) reference (described more in 5.4 Locator Attribute (href)). It 
is possible to address a portion of a resource. For example, if the whole resource is an XML 
document, a useful portion of that resource might be a particular element inside the document. 
Following a link to it might result, for example, in highlighting that element or scrolling to that 
point in the document. 

[Definition: When a link associates a set of resources, those resources are said to participate in 
the link.] Even though XLink links must appear in XML documents, they are able to associate all 
kinds of resources, not just XML‐encoded ones. 

One of the common uses of XLink is to create hyperlinks. [Definition: A hyperlink is a link that is 
intended primarily for presentation to a human user.] Nothing in XLink's design, however, 
prevents it from being used with links that are intended solely for consumption by computers. 

2.2 Arcs, Traversal, and Behavior 

[Definition: Using or following a link for any purpose is called traversal.] Even though some 
kinds of link can associate arbitrary numbers of resources, traversal always involves a pair of 
resources (or portions of them); [Definition: the source from which traversal is begun is the 
starting resource] and [Definition: the destination is the ending resource]. Note that the term 
"resource" used in this fashion may at times apply to a resource portion, not a whole resource. 

[Definition: Information about how to traverse a pair of resources, including the direction of 
traversal and possibly application behavior information as well, is called an arc]. If two arcs in a 
link specify the same pair of resources, but they switch places as starting and ending resources, 
then the link is multidirectional, which is not the same as merely "going back" after traversing a 
link. 

2.3 Resources in Relation to the Physical Location of a Linking Element 

[Definition: A local resource is an XML element that participates in a link by virtue of having as 
its parent, or being itself, a linking element]. [Definition: Any resource or resource portion that 
participates in a link by virtue of being addressed with a URI reference is considered a remote 
resource, even if it is in the same XML document as the link, or even inside the same linking 
216 
 
 
element.] Put another way, a local resource is specified "by value," and a remote resource is 
specified "by reference." 

[Definition: An arc that has a local starting resource and a remote ending resource goes 
outbound, that is, away from the linking element.] (Examples of links with such an arc are the 
HTML A element, HyTime "clinks," and Text Encoding Initiative XREF elements.) [Definition: If an 
arc's ending resource is local but its starting resource is remote, then the arc goes inbound.] 
[Definition: If neither the starting resource nor the ending resource is local, then the arc is a 
third‐party arc.] Though it is not required, any one link typically specifies only one kind of arc 
throughout, and thus might be referred to as an inbound, outbound, or third‐party link. 

To create a link that emanates from a resource to which you do not have (or choose not to 
exercise) write access, or from a resource that offers no way to embed linking constructs, it is 
necessary to use an inbound or third‐party arc. When such arcs are used, the requirements for 
discovery of the link are greater than for outbound arcs. [Definition: Documents containing 
collections of inbound and third‐party links are called link databases, or linkbases.] 

3 XLink Processing and Conformance 

This section details processing and conformance requirements on XLink applications and 
markup. 

[Definition: The key words must, must not, required, shall, shall not, should, should not, 
recommended, may, and optional in this specification are to be interpreted as described in 
[IETF RFC 2119].] 

3.1 Processing Dependencies 

XLink processing depends on [XML], [XML Names], [XML Base], and [IETF RFC 2396] (as updated 
by [IETF RFC 2732]). 

3.2 Markup Conformance 

An XML element conforms to XLink if: 

1. it has a type attribute from the XLink namespace whose value is one of "simple", 
"extended", "locator", "arc", "resource", "title", or "none", and 
2. it adheres to the conformance constraints imposed by the chosen XLink element type, 
as prescribed in this specification. 

This specification imposes no particular constraints on DTDs; conformance applies only to 
elements and attributes. 

217 
 
 
3.3 Application Conformance 

An XLink application is any software module that interprets well‐formed XML documents 
containing XLink elements and attributes, or XML information sets [XIS] containing information 
items and properties corresponding to XLink elements and attributes. (This document refers to 
elements and attributes, but all specifications herein apply to their information set equivalents 
as well.) Such an application is conforming if: 

1. it observes the mandatory conditions for applications ("must") set forth in this 
specification, and 
2. for any optional conditions ("should" and "may") it chooses to observe, it observes them 
in the way prescribed, and 
3. it performs markup conformance testing according to all the conformance constraints 
appearing in this specification. 

4 XLink Markup Design 

This section describes the design of XLink's markup vocabulary. 

Link markup needs to be recognized reliably by XLink applications in order to be traversed and 
handled properly. XLink uses the mechanism described in the Namespaces in XML 
Recommendation [XML Names] to accomplish recognition of the constructs in the XLink 
vocabulary. 

The XLink namespace defined by this specification has the following URI: 

http://www.w3.org/1999/xlink 

As dictated by [XML Names], the use of XLink elements and attributes requires declaration of 
the XLink namespace. For example, the following declaration would make the prefix xlink 
available within the myElement element to represent the XLink namespace: 

<myElement 
  xmlns:xlink="http://www.w3.org/1999/xlink"> 
  ... 
</myElement> 

Note: 

Most code examples in this specification do not show an XLink namespace declaration. The 
xlink prefix is used throughout to stand for the declaration of the XLink namespace on elements 
in whose scope the so‐marked attribute appears (on the same element that bears the attribute 
or on some ancestor element), whether or not an XLink namespace declaration is present in the 
example. 

218 
 
 
XLink's namespace provides global attributes for use on elements that are in any arbitrary 
namespace. The global attributes are type, href, role, arcrole, title, show, actuate, label, from, 
and to. Document creators use the XLink global attributes to make the elements in their own 
namespace, or even in a namespace they do not control, recognizable as XLink elements. The 
type attribute indicates the XLink element type (simple, extended, locator, arc, resource, or 
title); the element type dictates the XLink‐imposed constraints that such an element must 
follow and the behavior of XLink applications on encountering the element. 

Following is an example of a crossReference element from a non‐XLink namespace that has 
XLink global attributes: 

<my:crossReference 
  xmlns:my="http://example.com/" 
  xmlns:xlink="http://www.w3.org/1999/xlink" 
  xlink:type="simple" 
  xlink:href="students.xml" 
  xlink:role="http://www.example.com/linkprops/studentlist" 
  xlink:title="Student List" 
  xlink:show="new" 
  xlink:actuate="onRequest"> 
Current List of Students 
</my:crossReference> 

Using global attributes always requires the use of namespace prefixes on the individual 
attributes and the use of the type attribute on the element. 

4.1 XLink Attribute Usage Patterns 

While the XLink attributes are considered global by virtue of their use of the namespace 
mechanism, their allowed combinations on any one XLink element type depend greatly on the 
value of the special type attribute (see 5.3 XLink Element Type Attribute (type) for more 
information) for the element on which they appear. The conformance constraint notes in this 
specification detail their allowed usage patterns. Following is a summary of the element types 
(columns) on which the global attributes (rows) are allowed, with an indication of whether a 
value is required (R) or optional (O): 

simple  extended  locator  arc resource title


 
type  R  R  R  R R R

href  O   R 
   
role  O  O  O  O
 

219 
 
 
simple  extended  locator  arc resource title
 
arcrole  O  O
   
title  O  O  O  O O

show  O  O
   
actuate  O  O
   
label  O  O
     
from  O
     
to  O
     

(See also B Sample DTD for a non‐normative DTD that illustrates the allowed patterns of 
attributes.) 

This specification uses the convention "xxx‐type element" to refer to elements that must 
adhere to a named set of constraints associated with an XLink element type, no matter what 
name the element actually has. For example, "locator‐type element" would refer to all of the 
following elements: 

<locator xlink:type="locator" ... /> 
<loc xlink:type="locator" ... /> 
<my:pointer xlink:type="locator" ... /> 

4.2 XLink Element Type Relationships 

Various XLink element types have special meanings dictated by this specification when they 
appear as direct children of other XLink element types. Following is a summary of the child 
element types that play a significant role in particular parent element types. (Other 
combinations have no XLink‐dictated significance.) 

Parent type  Significant child types

simple  none 

extended  locator, arc, resource, title

220 
 
 
Parent type  Significant child types

locator  title 

arc  title 

resource  none 

title  none 

4.3 Attribute Value Defaulting 

Using XLink potentially involves using a large number of attributes for supplying important link 
information. In cases where the values of the desired XLink attributes are unchanging across 
individual instances in all the documents of a certain type, attribute value defaults (fixed or not) 
may be added to a DTD so that the attributes do not have to appear physically on element 
start‐tags. For example, if attribute defaults were provided for the xmlns:xlink, xmlns:my, type, 
show, and actuate attributes in the example in the introduction to 4 XLink Markup Design, the 
example would look as follows: 

<my:crossReference 
  xlink:href="students.xml" 
  xlink:role="http://www.example.com/linkprops/studentlist" 
  xlink:title="Student List"> 
Current List of Students 
</my:crossReference> 

Information sets that have been created under the control of a DTD have all attribute values 
filled in. 

4.4 Integrating XLink Usage with Other Markup 

This specification defines only attributes and attribute values in the XLink namespace. There is 
no restriction on using non‐XLink attributes alongside XLink attributes. In addition, most XLink 
attributes are optional and the choice of simple or extended link is up to the markup designer 
or document creator, so a DTD that uses XLink features need not use or declare the entire set 
of XLink's attributes. Finally, while this specification identifies the minimum constraints on XLink 
markup, DTDs that use XLink are free to tighten these constraints. The use of XLink does not 
absolve a valid document from conforming to the constraints expressed in its governing DTD. 

Following is an example of a crossReference element with both XLink and non‐XLink attributes: 

221 
 
 
<my:crossReference 
  xmlns:my="http://example.com/" 
  my:lastEdited="2000‐06‐10" 
  xmlns:xlink="http://www.w3.org/1999/xlink" 
  xlink:type="simple" 
  xlink:href="students.xml"> 
Current List of Students 
</my:crossReference> 

4.5 Using XLink with Legacy Markup 

Because XLink's global attributes require the use of namespace prefixes, non‐XLink‐based links 
in legacy documents generally do not serve as conforming XLink constructs as they stand, even 
if attribute value defaulting is used. For example, XHTML 1.0 has an a element with an href 
attribute, but because the attribute is a local one attached to the a element in the XHTML 
namespace, it is not the same as an xlink:href global attribute in the XLink namespace. 

5 XLink Elements and Attributes 

XLink offers two kinds of links: 

Extended links 

Extended links offer full XLink functionality, such as inbound and third‐party arcs, as well 
as links that have arbitrary numbers of participating resources. As a result, their 
structure can be fairly complex, including elements for pointing to remote resources, 
elements for containing local resources, elements for specifying arc traversal rules, and 
elements for specifying human‐readable resource and arc titles. 

XLink defines a way to give an extended link special semantics for finding linkbases; used 
in this fashion, an extended link helps an XLink application process other links. 

Simple links 

Simple links offer shorthand syntax for a common kind of link, an outbound link with 
exactly two participating resources (into which category HTML‐style A and IMG links 
fall). Because simple links offer less functionality than extended links, they have no 
special internal structure. 

While simple links are conceptually a subset of extended links, they are syntactically 
different. For example, to convert a simple link into an extended link, several structural 
changes would be needed. 

The following sections define the XLink elements and attributes. 

222 
 
 
5.1 Extended Links (extended‐Type Element) 

[Definition: An extended link is a link that associates an arbitrary number of resources. The 
participating resources may be any combination of remote and local.] 

The only kind of link that is able to have inbound and third‐party arcs is an extended link. 
Typically, extended linking elements are stored separately from the resources they associate 
(for example, in entirely different documents). Thus, extended links are important for situations 
where the participating resources are read‐only, or where it is expensive to modify and update 
them but inexpensive to modify and update a separate linking element, or where the resources 
are in formats with no native support for embedded links (such as many multimedia formats). 

The following diagram shows an extended link that associates five remote resources. This could 
represent, for example, information about a student's course load: one resource being a 
description of the student, another being a description of the student's academic advisor, two 
resources representing courses that the student is attending, and the last resource representing 
a course that the student is auditing. 

Without the extended link, the resources might be entirely unrelated; for example, they might 
be in five separate documents. The lines emanating from the extended link represent the 
association it creates among the resources. However, notice that the lines do not have 
directionality. Directionality is expressed with traversal rules; without such rules being 
provided, the resources are associated in no particular order, with no implication as to whether 
and how individual resources are accessed. 

The following diagram shows an extended link that associates five remote resources and one 
local resource (a special element inside the extended link element). This could represent the 
same sort of course‐load example as described above, with the addition of the student's grade 
point average stored locally. Again, the lines represent mere association of the six resources, 
without traversal directions or behaviors implied. 

223 
 
 

The XLink element type for extended links is any element with an attribute in the XLink 
namespace called type with a value of "extended". 

The extended‐type element may contain a mixture of the following elements in any order, 
possibly along with other content and markup: 

• locator‐type elements that address the remote resources participating in the link 
• arc‐type elements that provide traversal rules among the link's participating resources 
• title‐type elements that provide human‐readable labels for the link 
• resource‐type elements that supply local resources that participate in the link 

It is not an error for an extended‐type element to associate fewer than two resources. If the 
link has only one participating resource, or none at all, it is simply untraversable. Such a link 
may still be useful, for example, to associate properties with a single resource by means of 
XLink attributes, or to provide a placeholder for link information that will be populated 
eventually. 

Subelements of the simple or extended type anywhere inside a parent extended‐type element 
have no XLink‐specified meaning. Subelements of the locator, arc, or resource type that are not 
direct children of an extended‐type element have no XLink‐specified meaning. 

The extended‐type element may have the semantic attributes role and title (see 5.5 Semantic 
Attributes (role, arcrole, and title)). They supply semantic information about the link as a 
whole; the role attribute indicates a property that the entire link has, and the title attribute 
indicates a human‐readable description of the entire link. If other XLink attributes are present 
on the element, they have no XLink‐specified relationship to the link. If both a title attribute 
and one or more title‐type elements are present, they have no XLink‐specified relationship; a 
higher‐level application built on XLink will likely want to specify appropriate treatment (for 
example, precedence) in this case. 

224 
 
 
Example: Sample extended‐Type Element Declarations and Instance 

Following is a non‐normative set of declarations for an extended‐type element and its 
subelements. Parts of this example are reused throughout this specification. Note that the type 
attribute and some other attributes are defaulted in the DTD in order to highlight the attributes 
that are changing on a per‐instance basis. 

<!ELEMENT courseload ((tooltip|person|course|gpa|go)*)> 
<!ATTLIST courseload 
  xmlns:xlink     CDATA           #FIXED "http://www.w3.org/1999/xlink" 
  xlink:type      (extended)      #FIXED "extended" 
  xlink:role      CDATA           #IMPLIED 
  xlink:title     CDATA           #IMPLIED> 
 
<!ELEMENT tooltip ANY> 
<!ATTLIST tooltip 
  xlink:type      (title)         #FIXED "title" 
  xml:lang        CDATA           #IMPLIED> 
 
<!ELEMENT person EMPTY> 
<!ATTLIST person 
  xlink:type      (locator)       #FIXED "locator" 
  xlink:href      CDATA           #REQUIRED 
  xlink:role      CDATA           #IMPLIED 
  xlink:title     CDATA           #IMPLIED 
  xlink:label     NMTOKEN         #IMPLIED> 
 
<!ELEMENT course EMPTY> 
<!ATTLIST course 
  xlink:type      (locator)       #FIXED "locator" 
  xlink:href      CDATA           #REQUIRED 
  xlink:role      CDATA           #FIXED "http://www.example.com/linkprops/course" 
  xlink:title     CDATA           #IMPLIED 
  xlink:label     NMTOKEN         #IMPLIED> 
 
<!‐‐ GPA = "grade point average" ‐‐> 
<!ELEMENT gpa ANY> 
<!ATTLIST gpa 
  xlink:type      (resource)      #FIXED "resource" 
  xlink:role      CDATA           #FIXED "http://www.example.com/linkprops/gpa" 
  xlink:title     CDATA           #IMPLIED 
  xlink:label     NMTOKEN         #IMPLIED> 
 
<!ELEMENT go EMPTY> 
<!ATTLIST go 

225 
 
 
  xlink:type      (arc)           #FIXED "arc" 
  xlink:arcrole   CDATA           #IMPLIED 
  xlink:title     CDATA           #IMPLIED 
  xlink:show      (new 
                  |replace 
                  |embed 
                  |other 
                  |none)          #IMPLIED 
  xlink:actuate   (onLoad 
                  |onRequest 
                  |other 
                  |none)          #IMPLIED 
  xlink:from      NMTOKEN         #IMPLIED 
  xlink:to        NMTOKEN         #IMPLIED> 

Following is how XML elements using these declarations might look. 

<courseload> 
 
  <tooltip>Course Load for Pat Jones</tooltip> 
 
  <person 
    xlink:href="students/patjones62.xml" 
    xlink:label="student62" 
    xlink:role="http://www.example.com/linkprops/student" 
    xlink:title="Pat Jones" /> 
 
  <person 
    xlink:href="profs/jaysmith7.xml" 
    xlink:label="prof7" 
    xlink:role="http://www.example.com/linkprops/professor" 
    xlink:title="Dr. Jay Smith" /> 
  <!‐‐ more remote resources for professors, teaching assistants, etc. ‐‐> 
 
  <course 
    xlink:href="courses/cs101.xml" 
    xlink:label="CS‐101" 
    xlink:title="Computer Science 101" /> 
  <!‐‐ more remote resources for courses, seminars, etc. ‐‐> 
 
  <gpa xlink:label="PatJonesGPA">3.5</gpa> 
 
  <go 
    xlink:from="student62" 

226 
 
 
    xlink:to="PatJonesGPA" 
    xlink:show="new" 
    xlink:actuate="onRequest" 
    xlink:title="Pat Jones's GPA" /> 
  <go 
    xlink:from="CS‐101" 
    xlink:arcrole="http://www.example.com/linkprops/auditor" 
    xlink:to="student62" 
    xlink:show="replace" 
    xlink:actuate="onRequest" 
    xlink:title="Pat Jones, auditing the course" /> 
  <go 
    xlink:from="student62" 
    xlink:arcrole="http://www.example.com/linkprops/advisor" 
    xlink:to="prof7" 
    xlink:show="replace" 
    xlink:actuate="onRequest" 
    xlink:title="Dr. Jay Smith, advisor" /> 
 
</courseload> 
 

5.2 Simple Links (simple‐Type Element) 

[Definition: A simple link is a link that associates exactly two resources, one local and one 
remote, with an arc going from the former to the latter. Thus, a simple link is always an 
outbound link.] 

The purpose of a simple link is to be a convenient shorthand for the equivalent extended link. A 
single simple linking element combines the basic functions of an extended‐type element, a 
locator‐type element, an arc‐type element, and a resource‐type element. 

The following diagram shows the characteristics of a simple link; it associates one local and one 
remote resource, and implicitly provides a single traversal arc from the local resource to the 
remote one. This could represent, for example, the name of a student appearing in text which, 
when clicked, leads to information about the student. 

 
227 
 
 
Example: Simple Link Functionality Done with an Extended Link 

A simple link could be represented by an extended link in approximately the following way: 

<studentlink xlink:type="extended"> 
  <resource 
    xlink:type="resource" 
    xlink:label="local">Pat Jones</resource> 
  <locator 
    xlink:type="locator" 
    xlink:href="..." 
    xlink:label="remote" 
    xlink:role="..." 
    xlink:title="..." /> 
 
  <go 
    xlink:type="arc" 
    xlink:from="local" 
    xlink:to="remote" 
    xlink:arcrole="..." 
    xlink:show="..." 
    xlink:actuate="..." /> 
</studentlink> 

A simple link combines all the features above (except for the types and labels) into a single 
element. In cases where only this subset of features is required, the XLink simple linking 
element is available as an alternative to the extended linking element. The features missing 
from simple links are as follows: 

• Supplying arbitrary numbers of local and remote resources 
• Specifying an arc from its remote resource to its local resource 
• Associating a title with the single hardwired arc 
• Associating a role or title with the local resource 
• Associating a role or title with the link as a whole 

The XLink element for simple links is any element with an attribute in the XLink namespace 
called type with a value of "simple". The simple equivalent of the above extended link would be 
as follows: 

<studentlink xlink:href="...">Pat Jones</studentlink> 

The simple‐type element may have any content. The simple‐type element itself, together with 
all of its content, is the local resource of the link, as if the element were a resource‐type 
element. If a simple‐type element contains nested XLink elements, such contained elements 

228 
 
 
have no XLink‐specified relationship to the parent link. It is possible for a simple‐type element 
to have no content; in cases where the link is expected to be traversed on request, interactive 
XLink applications will typically generate some content in order to give the user a way to initiate 
the traversal. 

The simple‐type element effectively takes the locator attribute href and the semantic attributes 
role and title from the locator‐type element, and the behavior attributes show and actuate and 
the single semantic attribute arcrole from the arc‐type element. 

It is not an error for a simple‐type element to have no locator (href) attribute value. If a value is 
not provided, the link is simply untraversable. Such a link may still be useful, for example, to 
associate properties with the resource by means of XLink attributes. 

Example: Sample simple‐Type Element Declarations and Instance 

Following is a non‐normative set of declarations for a simple‐type element. 

<!ELEMENT studentlink ANY> 
<!ATTLIST studentlink 
  xlink:type      (simple)        #FIXED "simple" 
  xlink:href      CDATA           #IMPLIED 
  xlink:role      NMTOKEN         #FIXED "http://www.example.com/linkprops/student" 
  xlink:arcrole   CDATA           #IMPLIED 
  xlink:title     CDATA           #IMPLIED 
  xlink:show      (new 
                  |replace 
                  |embed 
                  |other 
                  |none)          #IMPLIED 
  xlink:actuate   (onLoad 
                  |onRequest 
                  |other 
                  |none)          #IMPLIED> 

Following is how an XML document might use these declarations. 

..., and <studentlink xlink:href="students/patjones62.xml">Pat 
Jones</studentlink> is popular around the student union. 

5.3 XLink Element Type Attribute (type) 

The attribute that identifies XLink element types is type. 

Constraint: type Value 

229 
 
 
The value of the type attribute must be supplied. The value must be one of "simple", 
"extended", "locator", "arc", "resource", "title", or "none". 

When the value of the type attribute is "none", the element has no XLink‐specified meaning, 
and any XLink‐related content or attributes have no XLink‐specified relationship to the element. 

Example: Sample type Attribute Declarations 

Following is a non‐normative attribute‐list declaration for type on an element intended to be 
simple‐type. 

<!ATTLIST xlink:simple 
  xlink:type      (simple)        #FIXED "simple" 
  ...> 

For an element that serves as an XLink element only on some occasions, one declaration might 
be as follows, where the document creator sets the value to "simple" in some circumstances 
and "none" in others. The use of "none" might be useful in helping XLink applications to avoid 
checking for the presence of an href value. 

<!ATTLIST commandname 
  xlink:type      (simple|none)   #REQUIRED 
  xlink:href      CDATA           #IMPLIED> 
 
 

1 Introduction 

XPath is the result of an effort to provide a common syntax and semantics for functionality 
shared between XSL Transformations [XSLT] and XPointer [XPointer]. The primary purpose of 
XPath is to address parts of an XML [XML] document. In support of this primary purpose, it also 
provides basic facilities for manipulation of strings, numbers and booleans. XPath uses a 
compact, non‐XML syntax to facilitate use of XPath within URIs and XML attribute values. XPath 
operates on the abstract, logical structure of an XML document, rather than its surface syntax. 
XPath gets its name from its use of a path notation as in URLs for navigating through the 
hierarchical structure of an XML document. 

In addition to its use for addressing, XPath is also designed so that it has a natural subset that 
can be used for matching (testing whether or not a node matches a pattern); this use of XPath 
is described in XSLT. 

XPath models an XML document as a tree of nodes. There are different types of nodes, 
including element nodes, attribute nodes and text nodes. XPath defines a way to compute a 
string‐value for each type of node. Some types of nodes also have names. XPath fully supports 

230 
 
 
XML Namespaces [XML Names]. Thus, the name of a node is modeled as a pair consisting of a 
local part and a possibly null namespace URI; this is called an expanded‐name. The data model 
is described in detail in [5 Data Model]. 

The primary syntactic construct in XPath is the expression. An expression matches the 
production Expr. An expression is evaluated to yield an object, which has one of the following 
four basic types: 

• node‐set (an unordered collection of nodes without duplicates) 
• boolean (true or false) 
• number (a floating‐point number) 
• string (a sequence of UCS characters) 

Expression evaluation occurs with respect to a context. XSLT and XPointer specify how the 
context is determined for XPath expressions used in XSLT and XPointer respectively. The 
context consists of: 

• a node (the context node) 
• a pair of non‐zero positive integers (the context position and the context size) 
• a set of variable bindings 
• a function library 
• the set of namespace declarations in scope for the expression 

The context position is always less than or equal to the context size. 

The variable bindings consist of a mapping from variable names to variable values. The value of 
a variable is an object, which can be of any of the types that are possible for the value of an 
expression, and may also be of additional types not specified here. 

The function library consists of a mapping from function names to functions. Each function 
takes zero or more arguments and returns a single result. This document defines a core 
function library that all XPath implementations must support (see [4 Core Function Library]). 
For a function in the core function library, arguments and result are of the four basic types. 
Both XSLT and XPointer extend XPath by defining additional functions; some of these functions 
operate on the four basic types; others operate on additional data types defined by XSLT and 
XPointer. 

The namespace declarations consist of a mapping from prefixes to namespace URIs. 

The variable bindings, function library and namespace declarations used to evaluate a 
subexpression are always the same as those used to evaluate the containing expression. The 
context node, context position, and context size used to evaluate a subexpression are 
sometimes different from those used to evaluate the containing expression. Several kinds of 
expressions change the context node; only predicates change the context position and context 
size (see [2.4 Predicates]). When the evaluation of a kind of expression is described, it will 
always be explicitly stated if the context node, context position, and context size change for the 

231 
 
 
evaluation of subexpressions; if nothing is said about the context node, context position, and 
context size, they remain unchanged for the evaluation of subexpressions of that kind of 
expression. 

XPath expressions often occur in XML attributes. The grammar specified in this section applies 
to the attribute value after XML 1.0 normalization. So, for example, if the grammar uses the 
character <, this must not appear in the XML source as < but must be quoted according to XML 
1.0 rules by, for example, entering it as &lt;. Within expressions, literal strings are delimited by 
single or double quotation marks, which are also used to delimit XML attributes. To avoid a 
quotation mark in an expression being interpreted by the XML processor as terminating the 
attribute value the quotation mark can be entered as a character reference (&quot; or &apos;). 
Alternatively, the expression can use single quotation marks if the XML attribute is delimited 
with double quotation marks or vice‐versa. 

One important kind of expression is a location path. A location path selects a set of nodes 
relative to the context node. The result of evaluating an expression that is a location path is the 
node‐set containing the nodes selected by the location path. Location paths can recursively 
contain expressions that are used to filter sets of nodes. A location path matches the 
production LocationPath. 

In the following grammar, the non‐terminals QName and NCName are defined in [XML Names], 
and S is defined in [XML]. The grammar uses the same EBNF notation as [XML] (except that 
grammar symbols always have initial capital letters). 

Expressions are parsed by first dividing the character string to be parsed into tokens and then 
parsing the resulting sequence of tokens. Whitespace can be freely used between tokens. The 
tokenization process is described in [3.7 Lexical Structure]. 

1 Introduction 

As increasing amounts of information are stored, exchanged, and presented using XML, the 
ability to intelligently query XML data sources becomes increasingly important. One of the great 
strengths of XML is its flexibility in representing many different kinds of information from 
diverse sources. To exploit this flexibility, an XML query language must provide features for 
retrieving and interpreting information from these diverse sources. 

XQuery is designed to meet the requirements identified by the W3C XML Query Working Group 
[XML Query 1.0 Requirements] and the use cases in [XML Query Use Cases]. It is designed to be 
a language in which queries are concise and easily understood. It is also flexible enough to 
query a broad spectrum of XML information sources, including both databases and documents. 
The Query Working Group has identified a requirement for both a non‐XML query syntax and 
an XML‐based query syntax. XQuery is designed to meet the first of these requirements. 
XQuery is derived from an XML query language called Quilt [Quilt], which in turn borrowed 
features from several other languages, including XPath 1.0 [XPath 1.0], XQL [XQL], XML‐QL 
[XML‐QL], SQL [SQL], and OQL [ODMG]. 

232 
 
 
[Definition: XQuery operates on the abstract, logical structure of an XML document, rather than 
its surface syntax. This logical structure, known as the data model, is defined in [XQuery/XPath 
Data Model (XDM)].] 

XQuery Version 1.0 is an extension of XPath Version 2.0. Any expression that is syntactically 
valid and executes successfully in both XPath 2.0 and XQuery 1.0 will return the same result in 
both languages. Since these languages are so closely related, their grammars and language 
descriptions are generated from a common source to ensure consistency, and the editors of 
these specifications work together closely. 

XQuery also depends on and is closely related to the following specifications: 

• [XQuery/XPath Data Model (XDM)] defines the data model that underlies all XQuery 
expressions. 
• [XQuery 1.0 and XPath 2.0 Formal Semantics] defines the static semantics of XQuery and 
also contains a formal but non‐normative description of the dynamic semantics that 
may be useful for implementors and others who require a formal definition. 
• The type system of XQuery is based on [XML Schema]. 
• The built‐in function library and the operators supported by XQuery are defined in 
[XQuery 1.0 and XPath 2.0 Functions and Operators]. 
• One requirement in [XML Query 1.0 Requirements] is that an XML query language have 
both a human‐readable syntax and an XML‐based syntax. The XML‐based syntax for 
XQuery is described in [XQueryX 1.0]. 

This document specifies a grammar for XQuery, using the same basic EBNF notation used in 
[XML 1.0]. Unless otherwise noted (see A.2 Lexical structure), whitespace is not significant in 
queries. Grammar productions are introduced together with the features that they describe, 
and a complete grammar is also presented in the appendix [A XQuery Grammar]. The appendix 
is the normative version. 

In the grammar productions in this document, named symbols are underlined and literal text is 
enclosed in double quotes. For example, the following production describes the syntax of a 
function call: 

[93]    FunctionCall    ::=    QName "(" (ExprSingle ("," ExprSingle)*)? ")"

The production should be read as follows: A function call consists of a QName followed by an 
open‐parenthesis. The open‐parenthesis is followed by an optional argument list. The argument 
list (if present) consists of one or more expressions, separated by commas. The optional 
argument list is followed by a close‐parenthesis. 

Certain aspects of language processing are described in this specification as implementation‐
defined or implementation‐dependent. 

233 
 
 
• [Definition: Implementation‐defined indicates an aspect that may differ between 
implementations, but must be specified by the implementor for each particular 
implementation.] 
• [Definition: Implementation‐dependent indicates an aspect that may differ between 
implementations, is not specified by this or any W3C specification, and is not required to 
be specified by the implementor for any particular implementation.] 

This document normatively defines the dynamic semantics of XQuery. The static semantics of 
XQuery are normatively defined in [XQuery 1.0 and XPath 2.0 Formal Semantics]. In this 
document, examples and material labeled as "Note" are provided for explanatory purposes and 
are not normative. 

2 Basics 

The basic building block of XQuery is the expression, which is a string of [Unicode] characters 
(the version of Unicode to be used is implementation‐defined.) The language provides several 
kinds of expressions which may be constructed from keywords, symbols, and operands. In 
general, the operands of an expression are other expressions. XQuery allows expressions to be 
nested with full generality. (However, unlike a pure functional language, it does not allow 
variable substitution if the variable declaration contains construction of new nodes.) 

Note: 

This specification contains no assumptions or requirements regarding the character set 
encoding of strings of [Unicode] characters. 

Like XML, XQuery is a case‐sensitive language. Keywords in XQuery use lower‐case characters 
and are not reserved—that is, names in XQuery expressions are allowed to be the same as 
language keywords, except for certain unprefixed function‐names listed in A.3 Reserved 
Function Names. 

[Definition: In the data model, a value is always a sequence.] [Definition: A sequence is an 
ordered collection of zero or more items.] [Definition: An item is either an atomic value or a 
node.] [Definition: An atomic value is a value in the value space of an atomic type, as defined in 
[XML Schema].] [Definition: A node is an instance of one of the node kinds defined in 
[XQuery/XPath Data Model (XDM)].] Each node has a unique node identity, a typed value, and 
a string value. In addition, some nodes have a name. The typed value of a node is a sequence 
of zero or more atomic values. The string value of a node is a value of type xs:string. The name 
of a node is a value of type xs:QName. 

[Definition: A sequence containing exactly one item is called a singleton.] An item is identical to 
a singleton sequence containing that item. Sequences are never nested—for example, 
combining the values 1, (2, 3), and ( ) into a single sequence results in the sequence (1, 2, 3). 
[Definition: A sequence containing zero items is called an empty sequence.] 

234 
 
 
[Definition: The term XDM instance is used, synonymously with the term value, to denote an 
unconstrained sequence of nodes and/or atomic values in the data model.] 

Names in XQuery are called QNames, and conform to the syntax in [XML Names]. [Definition: 
Lexically, a QName consists of an optional namespace prefix and a local name. If the 
namespace prefix is present, it is separated from the local name by a colon.] A lexical QName 
can be converted into an expanded QName by resolving its namespace prefix to a namespace 
URI, using the statically known namespaces [err:XPST0081]. [Definition: An expanded QName 
consists of an optional namespace URI and a local name. An expanded QName also retains its 
original namespace prefix (if any), to facilitate casting the expanded QName into a string.] The 
namespace URI value is whitespace normalized according to the rules for the xs:anyURI type in 
[XML Schema]. Two expanded QNames are equal if their namespace URIs are equal and their 
local names are equal (even if their namespace prefixes are not equal). Namespace URIs and 
local names are compared on a codepoint basis, without further normalization. 

Certain namespace prefixes are predeclared by XQuery and bound to fixed namespace URIs. 
These namespace prefixes are as follows: 

• xml = http://www.w3.org/XML/1998/namespace 
• xs = http://www.w3.org/2001/XMLSchema 
• xsi = http://www.w3.org/2001/XMLSchema‐instance 
• fn = http://www.w3.org/2005/xpath‐functions 
• local = http://www.w3.org/2005/xquery‐local‐functions (see 4.15 Function 
Declaration.) 

In addition to the prefixes in the above list, this document uses the prefix err to represent the 
namespace URI http://www.w3.org/2005/xqt‐errors (see 2.3.2 Identifying and Reporting 
Errors). This namespace prefix is not predeclared and its use in this document is not normative. 

Element nodes have a property called in‐scope namespaces. [Definition: The in‐scope 
namespaces property of an element node is a set of namespace bindings, each of which 
associates a namespace prefix with a URI, thus defining the set of namespace prefixes that are 
available for interpreting QNames within the scope of the element. For a given element, one 
namespace binding may have an empty prefix; the URI of this namespace binding is the default 
namespace within the scope of the element.] 

Note: 

In [XPath 1.0], the in‐scope namespaces of an element node are represented by a collection of 
namespace nodes arranged on a namespace axis, which is optional and deprecated in [XPath 
2.0]. XQuery does not support the namespace axis and does not represent namespace bindings 
in the form of nodes. However, where other specifications such as [XSLT 2.0 and XQuery 1.0 
Serialization] refer to namespace nodes, these nodes may be synthesized from the in‐scope 
namespaces of an element node by interpreting each namespace binding as a namespace node. 

235 
 
 
[Definition: Within this specification, the term URI refers to a Universal Resource Identifier as 
defined in [RFC3986] and extended in [RFC3987] with the new name IRI.] The term URI has 
been retained in preference to IRI to avoid introducing new names for concepts such as "Base 
URI" that are defined or referenced across the whole family of XML specifications. 

 
 
 
 
 
 
 
236 
 
 
II UNIT 
 

•• BBuussiinneessss  M Weebb  SSeerrvviicceess  ––  BB22bb  ––  BB22cc    
Moottiivvaattiioonnss  FFoorr  W
•• TTeecchhnniiccaall  M
Moottiivvaattiioonnss     
•• LLiim
miittaattiioonnss  O
Off  CCoorrbbaa  AAnndd  D
Dccoom
m  
•• SSeerrvviiccee‐‐O
Orriieenntteedd  AArrcchhiitteeccttuurree  ((SSooaa))   
•• AArrcchhiitteeccttiinngg  W
Weebb  SSeerrvviicceess  
•• IIm
mpplleem
meennttaattiioonn  VViieew
w   
•• W
Weebb  SSeerrvviicceess  TTeecchhnnoollooggyy  SSttaacckk  
•• LLooggiiccaall  VViieew
w   
•• CCoom
mppoossiittiioonn  O
Off  W
Weebb  SSeerrvviicceess  
•• D
Deeppllooyym
meenntt  VViieew m  AApppplliiccaattiioonn  SSeerrvveerr  TToo  PPeeeerr  TToo  PPeeeerr  
w  ––  FFrroom
•• PPrroocceessss  VViieew
w  
•• LLiiffee  IInn  TThhee  RRuunnttiim
mee  
 
 
 
 
 
 
 
 
 
 
 
 
 
 
237 
 
 
 
Introduction  
 
A short history of Web services 
 
The  Internet  began  its  success  story  in  the  early  nineties,  even  though  it  was  used  in  the 
academic  world  before  for  many  years.  The  main  driver  for  the  Internet’s  success  was  the 
World Wide Web, whose main innovation was the easy access to information, from any place, 
using  standard  Internet  protocols  and  a  simple  data  access  protocol  that  enabled  the 
implementation browsers on  
a  variety  of  platforms.  Together  with  the  spread  of  the  WWW,  the  Internet  and  its  related 
technologies became the de facto standard to connect computers all around the world.  
With the spread of the Internet, it became clear that the infrastructure that was introduced by 
the  Internet  could  be  used  not  just  to  retrieve  information  that  was  to  be  presented  using  a 
browser (called human‐to‐application, H2A, scenarios).  
Rather,  there  was  also  an  increased  demand  for  application‐to‐application  (A2A) 
communication  using  the  existing  technologies.  And,  it  was  hoped  that  the  existing  protocols 
could be used for this purpose.  
However,  it  soon  became  clear  that  this  was  not  the  case.  HTTP  had  been  designed  with  the 
retrieval  of  information  in  mind,  following  a  very  simple  access  path  that  basically  relies  on 
documents  being  linked  together  by  means  of  hypertexts.  The  protocol  does  not  provide  for 
complex  operations  that  arise  from  A2A  scenarios.  And  some  of  the  protocols  that  were 
defined  at  this  time  could  not  be  used  either because  they  did  not  fit  into  the  Web  world  or 
they were too  
restrictive.  
In late1999, Microsoft® published an XML‐based protocol, called SOAP that could be used for 
A2A scenarios. As it was one among many protocols suggested, it may due to the fact that IBM 
started  supporting  SOAP  in  early2000  that  eventually  lead  to  a  public  acceptance  of  SOAP  by 
the industry.  
At this point in time, SOAP was just a protocol to perform complex A2A scenarios. However, it 
quickly  gained  popularity  and  it  was  clear  that  there  was  a  need  for  better  describing  and 
finding  the  services  that  were  implemented  using  SOAP.  The  term  Web  services  was  coined 
several  months  later,  when  IBM,  Microsoft,  and  Ariba  jointly  published  the  Web  Services 
Description Language (WSDL). Eventually, UDDI was also introduced, thus completing the set of  
standards and protocols that make up the basis of Web services. 
 

238 
 
 

As  Figure  5.1  shows,  Web  services  builds  on  SOAP's  capability  for  distributed,  decentralized 
network  communication  by  adding  new  protocols  and  conventions  that  expose  business 
functions  to  interested  parties  over  the  Internet  from  any  Web‐connected  device.  As  we 
discussed in Chapter 1, we're moving into a new computing paradigm based on the assembly of 
constituent  parts.  SOAP,  for  example,  is  not  a  stand‐alone  technology,  but  the  result  of 
synergies  between  XML  and  HTTP.  This  phenomenon  of  emergence  has  not  been  lost  on  the 
major industry players, who are actively working to update their existing infrastructures to keep 
pace with the changes wrought by SOAP‐based messaging for the global Web. 

Web services is a technology and process for discovery and connection. 

Web  services  represents  an  industry‐wide  response  to  the  need  for  a  flexible  and  efficient 
business  collaboration  environment.  Technically,  it  is  a  way  to  link  loosely  coupled  systems 
using  technology  that  doesn't  bind  them  to  a  particular  programming  language,  component 
model,  or  platform.  Practically,  it  represents  a  discrete  business  process  with  supporting 
protocols that functions by describing and exposing itself to users of the Web, being invoked by 
a remote user, and returning a response. It includes: 

• Describing:  Web  services  describes  its  functionality  and  attributes  so  that  other 
applications can figure out how to use it. 

239 
 
 
• Exposing:  Web  services  register  with  a  repository  that  contains  a  white  pages  holding 
basic  service‐provider  information,  a  yellow  pages  listing  services  by  category,  and  a 
green pages describing how to connect and use the services. 
• Being invoked: When a Web service has been located, a remote application can invoke 
the service. 
• Returning  a  response:  When  a  service  has  been  invoked,  results  are  returned  to  the 
requesting application. 

The driving force behind Web services is the desire to allow businesses to use the Internet to 
publish, discover, and aggregate other Web services using the global underpinning of SOAP. The 
fact  that  the  delivery  of  Web  services  requires  only  the  Internet  means  that  legacy  code  and 
data  as  well  as  object  systems  can  plug  into  the  Web  services  framework.  This  capability  is 
expected  to  result  in  new  products,  business  processes,  and  value  chains  with  global  scope, 
deliverable over wired or wireless networks. How these will emerge is anyone's guess. But the 
track  record  of  the  Web,  XML,  and  now  SOAP  indicates  that  new  technologies  will  rapidly 
emerge. 

Business Motivation for Web Services  

Web services are the design center that can enable your company to rapidly take advantage of 
XML. Web services are based on XML and are the application model adopted by the giants of 
the IT industry. Companies such as Microsoft, IBM, Sun, HP, BEA and Software AG are building 
the  technologies  that  will  make  the  vision  of  Web  services  a  reality.  In  this  chapter,  we  will 
explore what Web services are and how you can take advantage of them by building a simple 
Web services architecture for your company. This architecture is entirely based on standards, 
but at the same time allows you to reuse existing infrastructure. 
By now you should have heard something about Web services. The topic is hard to avoid. The 
media  machine  is  busy  cranking  out  the  hype  that  has  become  so  typical  of  our  industry. 
”Revolutionary.”  ”A  breakthrough.”  ”Microsoft,  SAP,  HP,  Sun  and  IBM  joining  ranks.” 
”Transforming software into services.” The buzzwords keep flying. There is not an IT publication 
today that does not spout forth a never ending flood of abbreviations like WSDL, UDDI, SOAP, 
RDF, XSLT, etc. And, like with so many other technologies, the average reader is left with the 
question:  ”What  is  in  it  for  me?”  This  chapter  is  devoted  to  demystifying  the  topic  of  Web 
services and to explaining what Web services are and how to apply them to increase rev‐ 
enue for your corporation and to drive down the IT cost associated with building new products, 
services and revenue channels. If the information in this chapter whets your appetite, there is 
plenty  of  additional  information  available  on  the  Internet.  Just  type  ”Web  services”  into  your 
favorite search engine and prepare to be blown away by the wealth of information available on 
this topic. For now, the most important fact to remember is that Web services form the design 
center around XML, the most important IT standard for the next two decades. 
 
Let’s begin with looking at the term Web services. The use of the term ”Web” implies that Web 
services  are  based  on  the  World  Wide  Web.  While  this  is  true,  it  is  actually  quite misleading. 
Although  the  technologies  for  Web  services  are  based  on  the  standards  that  have  evolved  in 
240 
 
 
the World Wide Web Consortium (W3C), Web services are really not limited to the Web itself. 
(Remember that the Web is really the graphical user interface that made the Internet easy to 
use.)  Web  services  are  a  new  approach  for  building,  extending,  integrating  and  deploying 
applications based on XML. 
This new approach builds applications that can facilitate the communication process between 
humans  and  machines  (the  Web),  as  well  as  the  communication  process  between  machines 
(the  Internet)  and  the  communication  process  between  applications  (application  integration). 
By  simplifying  communications  between  humans,  machines  and  applications  based  on  a 
common  standard  (XML),  Web  services  are  an  important  building  block  on  the  path  to  total 
business integration and the unbounded enterprise. (Seechapter 1.) Web services allow your IT 
department to do a number of extremely significant things, including but not limited to: 
• reuse existing applications. 
• tie existing applications into a single view. 
• make these applications available to employees, partners and customers. 
• build application extensions that model your business process. 
• flow information across departments, business units or corporations. 
If this sounds interesting to you, you should also know that these things can be accomplished 
very quickly and at a very low cost when compared to traditional approaches. The main reason 
why Web services are finding such rapid approval in the IT industry is their ability to reduce IT 
costs  while  delivering  the  capability  of  building  new  revenue  models  based  on  your  core 
business. In addition, Web services can be the model for new application types that need to be 
deployed  very  rapidly.  You  might  wonder:  ”Why  is  this  different?  Have  we  not  seen  these 
claims  before?”  The  answer  is  yes,  we  have  seen  the  claims,  but  there  has  been  a  crucial 
element missing in the equation. That element is called XML – the Extensible Markup Language. 
XML  has  been  accepted  in  the  industry  as  the  de  facto  standard  for  storing,  exchanging  and 
publishing  electronic  documents.  (More  information  about  XML  can  be  obtained  in  the  book 
”The  XML  Shockwave”  by  the  same  author.).  So  what  does  XML  have  do  with  Web  services? 
Everything. Period. 
Web services (and their benefits of cost reduction and speed of implementation) are based on 
the  assumption  that  every  single  element  and  every  single  buzzword  in  the  family  of  Web 
services technologies must work with XML, and, as a matter of fact, are driven by the concept 
of XML documents. To some extent, Web services are the ”killer application” for XML,much in 
the same way the Web browser was the killer application for the Internet. The Web browser 
made  the  Internet  easy  to  use  and  spawned  an  explosion  of  new  applications  that  allow 
average users to access information. There are a lot of benefits to this approach, and the fact 
that more than 400 million people are using the Web proves that there is ampledemand for this 
kind of approach. There is a downside, however. The Web is all about graphical user interfaces 
to applications. What the Web fails to accomplish is the ability for applications and machines to 
communicate  directly  and  automatically  based  on  common  standards.  This  is  where  a  huge 
potential  for  internal  cost  savings  still  remains  untapped.  According  to  research  done  at  the 
Massachusetts  Institute  of  Technology  (”The  Unfinished  Revolution,”  by  Michael  Dertouzos) 
about 50 percent of the world economy is based on office work. This is a huge number. What 
this means is that in order to gain more productivity, we need to build more automation into 
our business processes. We cannot continue to assume that a human being sitting in front of a 
Web  browser  is  the  answer  to  the  productivity  challenge  every  company  faces.  We  need 
simple,  automatic,  machine‐to‐machine  and  application‐to‐application  communication.  But 
241 
 
 
how? How can this be done without the huge cost that used to be associated with integration 
software such as CORBA and EDI? 
Enter XML. XML is the standard accepted worldwide that helps corporations and IT companies 
define  the  meaning  of  data.  Once  you  have  defined  the  meaning  of  data,  you  can  build  XML 
documents  that  describe  themselves  that  can  be  stored,  exchanged  and  published  with  a 
minimum of effort. XML is the technology that enables standards‐based machine‐to‐ machine 
communications and application integration, process integration and business automation. XML 
is well accepted. According to Giga Corporation, about 95 percent of companies surveyed have 
already  started  using  XML,  and  about  30  percent  of  companies  have  put  their  first  mission‐
critical projects in place based on XML. But XML is a basic technology that needs an approach, a 
model and a design center to succeed in the long term. Web services are the design center for 
XML based applications. 
 
XML is taking the world of IT by storm, and the adoption of the Web services model is becoming 
the killer application for XML. To understand this a bit more, we need to look at the second part 
of the term Web services, i.e. services. Like the term Web in Web services, the word services is 
correct in describing what Web services seek to accomplish, but it is also misleading. 
A Web Service really is a self‐contained application that is fully XML enabled. A Web Service can 
do the following things automatically, without requiring human intervention: 
 
• Describe a business function that is available in your corporation, for example a request for 
credit. 
• Publish that business function to other applications or end users based on standard Internet 
technology such as Web servers, application servers, integration servers or XML servers. 
• Receive XML documents as valid input to this business function. 
• Store those XML documents to preserve the integrity of the request and to enable auditing 
and tracking. 
• Evaluate and process that input. 
•  Route  that  input  into  a  processing  application  that  could  be  another  Web  service  or  a 
traditional application. 
• Produce a result, for example the approval of credit. 
• Store that result to preserve the integrity of the output and to enable auditing and tracking. 
• Route the result to the consumer of the business function, which could be a user, a device 
such as a mobile phone, a PC, a mainframe or any other entity that can be reached over the 
Internet. 
 
 
Web Services 
Introduction 
  In this chapter we are going to see following, 
1. What is a Web Service? 
2. Why we need a Web Service? 
3. ASP.Net Web Services 
4. Use Data in Web Services 
242 
 
 
 
What is a Web Service? 

The  Internet  is  quickly  evolving  from  today's  Web  sites  that  just  deliver  user  interface 
pages  to  browsers  to  a  next  generation  of  programmable  Web  sites  that  directly  link 
organizations, applications, services, and devices with one another. These programmable 
Web sites become more than passively accessed sites ‐ they become reusable, intelligent 
Web Services. They allow different applications to share business logic over the network. 
  The  technical  definition  of  a  Web  Service  is  programmable  application  logic 
accessible via Standard web protocols. 
Programmable  Application  Logic:  A  Web  Service  is  Application  non‐specific.  The 
application  logic  can  be  implemented  by  components,  by  PERL  scripts,  or  by  any  other 
mechanism that supports XML. 
Standard  Web  Protocols:  Web  Services  use  Internet  transport  protocols  such  as  SOAP, 
HTTP and SMTP. 

Why we need a Web Service? 

Server and client need to understand following: 

• Implementation details of a particular service, 
• Service deployment, 
• Security types and trusts, etc. 
The common language runtime provides built‐in support for creating and exposing Web 
Services, using a programming abstraction that is consistent and familiar to both ASP.NET 
Web Forms developers and existing Visual Basic users. The resulting model is scalable and 
extensible, and supports open Internet standards (HTTP, XML, SOAP, WSDL). Therefore it 
can be accessed and consumed from any client or Internet‐enabled device.  
 

One  important  feature  of  the  Web  services  based  computing  model  is  that  a  client  need  not 
know the language in which XML Web services are implemented. The client just needs to know 
the location of an XML Web service and the methods that the client can call on the service. 

Web  services  use  XML‐based  messaging  to  send  and  receive  data,  which  enables 
heterogeneous  applications  to  interoperate  with  each  other.  You  can  use  Web  services  to 
integrate  applications  that  are  written  in  different  programming  languages  and  deployed  on 
different platforms. You can deploy Web services within an intranet as well as on the Internet. 
While  the  Internet  brings  users  closer  to  organizations,  Web  services  allow  organizations  to 
integrate their applications. 

Web Services Infrastructure 
243 
 
 
The Web services infrastructure provides several components that enable client applications to 
locate and consume Web services. These components include the following: 

XML Web services directories (UDDI) 

These  directories  provide  a  central  place  to  store  published  information  about  Web 
services.  The  Universal  Description,  Discovery,  and  Integration  (UDDI)  specifications 
define the guidelines for publishing information about Web services. The XML schemas 
associated  with  UDDI  define  four  types  of  information  that  you  must  publish  to  make 
your  Web  service  accessible.  This  information  includes  business  information,  service 
information,  binding  information,  and  service  specifications.  Microsoft  provides  one 
such directory service, which is located at http://uddi.microsoft.com. 

Web services discovery. (WSDL) 

Using  this  process,  clients  locate  the  documents  that  describe  a  Web  service  using 
WSDL.  The  discovery  process  enables  clients  to  know  about  the  presence  of  a  Web 
service and about the location of a particular XML Web service. 

Web services description.  

This  component  provides  information  that  enables  you  to  know  which  operations  to 
perform  on  a  Web  service.  The  Web  service  description  is  an  XML  document  that 
specifies the format of messages that a Web service can understand.  

Web service wire formats.  

To  enable  communication  between  disparate  systems,  Web  services  use  open  wire 
formats.  Open  wire  formats  are  the  protocols  that  can  be  understood  by  any  system 
that  is  capable  of  supporting common  Web  standards,  such  as  HTTP  and  SOAP.  The 
HTTP‐GET and HTTP‐POST protocols are the standard Web protocols that allow you to 
send parameters as name‐value pairs. The HTTP‐GET protocol allows you to send URL‐
encoded  parameters  as  name‐value  pairs  to  an  XML  Web  service.  The  HTTP‐GET 
protocol requires you to append the parameter name‐value pairs to the URL of the Web 
service. You can also use the HTTP‐POST protocol to URL‐encode and pass parameters 
to the Web service as name‐value pairs. However, the parameters are passed inside the 
actual request message and not appended to the URL of the Web service. 

The  SOAP  protocol  allows  you  to  exchange  structured  and  typed  information  between  the 
applications  on  the  Internet.  The  SOAP  protocol  consists  of  four  parts.  The  first  part  is 
mandatory and defines the envelope that contains the message. The SOAP envelope is the basic 
unit  of  exchange  between  the  processors  of  SOAP  messages.  The  second  part  defines  the 
optional data encoding rules that you use to encode application‐specific data types. The third 
part  defines  the  request/response  pattern  of  message  exchanges  between  Web services.  The 
fourth part, which is optional, defines the bindings between the SOAP and HTTP protocols. 

244 
 
 
How  components  of  the  XML  Web  services  infrastructure  enable  clients  to  locate  and  call 
methods on XML Web services. 

When a client accesses a UDDI service to locate a Web service, the UDDI service returns a URL 
to  the  discovery  document  of  the  Web  service.  A  discovery  document  is  a  .disco  file,  which 
contains  the  link  to  the  resources  that  describe  a  Web  service.  A  discovery  file  is  an  XML 
document that enables programmatic discovery of a Web service. After the client receives the 
URL  to  the  discovery  document,  the  client  requests  a  server,  which  returns  the  discovery 
document  to  the  client.  The  contents  of  a  sample  discovery  document  are  shown  in  the 
following code. 

XML 

<?xml version="1.0" ?> 

<disco:discovery xmlns:disco="http://schemas.xmlsoap.org/disco" 

    xmlns:wsdl="http://schemas.xmlsoap.org/disco/wsdl"> 
245 
 
 
   <wsdl:contractRef ref="http://www.seed.com/MyWebService.asmx?WSDL"/> 

</disco:discovery> 

The client uses the information in the discovery document and requests a server to return the 
service description of a Web service. The service description is a .wsdl file and enables a client 
to interact with a Web service. 

Next the client invokes methods on an XML Web service. 

The process of communication between a client and an XML Web service is similar to a remote 
procedure  call  (RPC).  The  client  uses  a  proxy  object  of  the  XML  Web  service  on  the  local 
computer to call methods on the Web service.  

Figure shows the process of communication between a client and a Web service. 

 
 

Client and Web service communication  

As  shown  in  Figure,  the  interaction  between  a  client  and  a  Web  service  consists  of  several 
phases. The following tasks are performed during these phases: 

246 
 
 
1. The  client  creates  an  object  of  the  Web  service  proxy  class  on  the  same  computer  on 
which the client resides. 
2. The client calls a method on the proxy object. 
3. The  Web  services  infrastructure  on  the  client  system  serializes  the  method  call  and 
arguments into a SOAP message and sends it to the Web service over the network. 
4. The infrastructure on the server on which the Web service resides deserializes the SOAP 
message and creates an instance of the Web service. The infrastructure then calls the 
method with the arguments on the Web service. 
5. The Web service executes the method and returns the value with any out parameters to 
the infrastructure. 
6. The  infrastructure  serializes  the  return  value  and  any  out  parameters  into  a  SOAP 
message and sends them to the client over the network. 
7. The infrastructure on the client computer deserializes the SOAP message containing the 
return value and any out parameters and sends them to the proxy object. 
8. The proxy object sends the return value and any out parameters to the client. 

To build Web services that the clients can consume, you use the ASP.NET infrastructure, which 
is  an  integral  part  of  the  .NET  Framework.  Visual  Studio  .NET  provides  tools  to  build,  deploy, 
and publish your Web services using ASP.NET. 

Benefits of Web Services 

Experts  and  visionaries  believe  that  the  benefits  of  XML  Web  services  will  be  instrumental  in 
propelling explosive business growth over the next few years. One of the major benefits is Web 
services'  ease  of  integration.  You  will  easily  integrate  your  software  with  other  pieces  of 
software.  You  can  run  on  all  kinds  of  machines,  from  the  desktop  to  the  mainframe,  either 
within your enterprise or at external sites. This ease of integration will enable tighter business 
relationships and more efficient business processes. 

With  Web  services  readily  available,  and  as  the  pool  of  XML  Web  services  grows,  you  will  be 
able  to  find  software  modules  that  can  be  integrated  into  your  own  application,  by  finding  it 
and  integrating  it  through  XML  Web  services.  Integrate  with  existing  Web  services  instead  of 
reinventing them. The bottom line is that you will be able to develop applications much faster 
than before. 

An integral part of the XML Web services programming model, is the ease of integration with 
external data sources. No longer does each application need to copy and maintain external data 
sources. You can request and get information in real time, and transform it to your particular 
format.  This  will  allow  you  to  deliver  individualized  software  and  services,  while  your 
maintenance burden is reduced. 

Consumers will enjoy ease of use when using XML Web services‐based applications. XML Web 
services  link  applications,  services,  and  devices  together.  Using  Web  services  will  be  an 

247 
 
 
integrated experience that excels in its simplicity. XML Web services give users the ability to act 
on information any time, any place, and from any smart device. 

Businesses will love Web services because it will force them to streamline their processes. All 
suppliers  will  use  the  same  language  to  describe  their  offerings.  An  XML  Web  service  is  a 
simple, reliable way to blend existing systems with new applications and services. 

Microsoft  is  already  sporting  several  commercial  applications  that  were  written  in  a  record 
speed, thanks to the use of XML Web services. The first one is from Dollar Rent‐A‐Car. In two 
weeks, programmers built, tested, and deployed a Web Services‐based solution that translates 
reservation  requests  and  data  between  the  company's  mainframe‐based  reservation  system 
and an airline partner's UNIX servers. Dollar can now reuse the same integration model to link 
their reservation system with other airline or hotel partners. The second case is expedia.com. 
This  is  a  site  that  will  find  you  the  lowest  price  itinerary.  They  are  now  in  the  process  of 
transforming itineraries into communication centers. These centers are Web services that users 
can access to get relevant and timely information at their convenience. With this new service, 
Expedia  hopes  to  attract  new  customers  and  further  strengthen  the  loyalty  of  their  existing 
customer base. 

z B2B  (Business‐to‐Business) 
Companies doing business with each other such as manufacturers selling to distributors 
and  wholesalers  selling  to  retailers.  Pricing  is  based  on  quantity  of  order  and  is  often 
negotiable. 
248 
 
 
z B2C  (Business‐to‐Consumer) 
Businesses selling to the general public typically through catalogs utilizing shopping cart 
software. By dollar volume, B2B takes the prize, however B2C is really what the average 
Joe has in mind with regards to ecommerce as a whole. 

Constraints of Ecommerce  

z Time for delivery of physical products  
z Physical product, supplier & delivery uncertainty .  
z Perishable goods  
z Limited and selected sensory information  
z Returning goods.  
z Privacy, security, payment, identity, contract.  
z Defined services & the unexpected .  
z Personal service  

   What is B2C? 

• B2C Commerce: Interactions relating to the purchase and sale of goods and services between 
a business and consumer—retail transactions. 

• “Novelty” is that retail transaction is done on the Internet, rather than a “brick and mortar” 
store location. 

• Technical evolution of B2C from “brick and mortar” model not new. 

Problem 1: I want to use your Web Service. 

• Where can I find it? 
• What messages are accepted / generated? What syntax? 
• How should they be encoded? 

Problem 2: Many others also want to offer Web Services 

• Need standard format for describing Web Services 

    

Revenue Models 

• Sell goods and services and take a cut    (just like B&M retailers).(e.g., Amazon, E*Trade, Dell) 

• Advertising 

– Ads only (original Yahoo) 
249 
 
 
– Ads in combination with other sources 

• Transaction fees 

• Sell digital content through subscription. (e.g., WSJ online, Economist Intelligence  

Wire) 

Open Issues in E‐commerce 

• Globalization 
• Contractual and Financial Issues 
• Ownership 
• Privacy and Security 
• Interconnectivity and Interoperability 
• Deployment 
• Main Attraction:   
Lower Retail Prices 
• “B2C Pure Plays” could eliminate intermediaries, storefront costs, some distribution 
costs, etc.  
• Archetype: www.amazon.com 
Basic Problems Encountered Immediately 
• “Customer‐Acquisition Costs” are huge. 
• Service is technically commoditizable, and there are no significant network effects. 
• Customers’ switching costs are tiny.    (Lock‐in to online book‐buying is high. Lock‐in 
to  
Amazon is low.  Recall Netscape and IE.) 
• Competition is fierce in almost all segments.  Few e‐tailers are profitable. 
• Investors have run out of money and patience. 

250 
 
 

 
251 
 
 
 

Web Services Description Language 

• Defines the contract/interface for using a Web Service:  
o URI 
o Messages accepted & generated (Syntax and datatypes) 
o Access protocol 
o Message encoding 
• Standard format (use of XML) 

Web Services Description examples 

1. get a temperature for a given US town 
2. set the temperature for a given US town 
3. Web Services Description example 
4.  
5. <definitions name="Temperature" 
6.   targetNamespace="http://weather.com/USservice" 
7.   [... xmlns declarations ...]> 
8.  
9. <types> 
10.   <xsd:schema 
11.     targetNamespace="http://wheather.com/USservice.xsd"> 
12.       <xsd:element name="temperature" 
13.          type='xsd:short' /> 
14.   </xsd:schema> 
15. </types> 
16.  
17. <message name="message1"> 
18.   <part name="zipcode" 
19.         type="xsd:nonNegativeInteger"/>  
20. </message> 
21. <message name="message2"> 
22.   <part name="temperature" type="xus:temperature"/> 
23. </message> 
24.  
25. <interface name="Temperature1"> 
26.   <operation name="getTemperature"> 
27.     <input message="us:message1"/> 
28.     <output message="us:message2"/> 
29.   </operation> 

252 
 
 
30. </interface> 
31.  
32. <interfaceBinding name="TemperatureGETBinding" 
33.       type="us:Temperature1"> 
34.  <http:binding verb="GET"/> 
35.  <operation name="us:getTemperature"> 
36.    <http:operation  
37.      location="GetTemperature"/> 
38.    <input> 
39.      <http:urlEncoded /> 
40.    </input> 
41.    <output> 
42.      <mime:content type="application/xml"/> 
43.    </output> 
44.  </operation> 
45. </interfaceBinding> 
46.  
47. <service name="USTemperatureService"> 
48.   <endpoint name="get" 
49.     binding="us:TemperatureGETBinding"> 
50.     <http:address 
51.       location="http://weather.com/" /> 
52.   </endpoint> 
53. </service> 
54.  
55. </definitions> 
56. <definitions name="Temperature" 
57.   targetNamespace="http://weather.com/USservice" 
58.   [... xmlns declarations ...]> 
59.  
60. <message name="message3"> 
61.   <part name="zipcode" 
62.         type="xsd:nonNegativeInteger"/> 
63.   <part name="temperature" type="xsd:short"/> 
64. </message> 
65.  
66. <interface name="Temperature2"> 
67.   <operation name="setTemperature"> 
68.     <input message="us:message3"/> 
69.   </operation> 
70. </interface> 
71. </interface> 
72.  
73. <interfaceBinding name="TemperaturePOSTBinding" 
74.       type="us:Temperature2"> 
75.  <http:binding verb="POST"/> 
253 
 
 
76.  <operation name="us:setTemperature"> 
77.    <http:operation 
78.      location="SetTemperature"/> 
79.    <input> 
80.      <mime:content 
81.        type="application/x‐www‐form‐urlencoded"/> 
82.    </input> 
83.  </operation> 
84. </interfaceBinding> 
85.  
86. <service name="USTemperatureService"> 
87.   <endpoint name="set" 
88.     binding="us:TemperaturePOSTBinding"> 
89.     <http:address 
90.       location="http://weather.com/" /> 
91.   </endpoint> 
92. </service> 
93.  
94. </definitions> 
 

What is CORBA? 

Common  Object  Request  Broker  Architecture  (CORBA)  is  a  competing  distributed  systems 
technology that offers greater portability than remote method invocation. Unlike RMI, CORBA 
isn't tied to one language, and as such, can integrate with legacy systems of the past written in 
older languages, as well as future languages that include support for CORBA. CORBA isn't tied to 
a single platform (a property shared by RMI), and shows great potential for use in the future. 
That said, for Java developers, CORBA offers less flexibility, because it doesn't allow executable 
code to be sent to remote systems. 

CORBA services are described by an interface, written in the Interface Definition Language (IDL). 
IDL  mappings  to  most  popular  languages  are  available,  and  mappings  can  be  written  for 
languages  written  in  the  future  that  require  CORBA  support.  CORBA  allows  objects  to  make 
requests  of  remote  objects  (invoking  methods),  and  allows  data  to  be  passed  between  two 
remote  systems.  Remote  method  invocation,  on  the  other  hand,  allows  Java  objects  to  be 
passed  and  returned  as  parameters.  This  allows  new  classes  to  be  passed  across  virtual 
machines for execution (mobile code). CORBA only allows primitive data types, and structures 
to be passed ‐ not actual code. 

Under communication between CORBA clients and CORBA services, method calls are passed to 
Object Request Brokers (ORBs). These ORBs communicate via the Internet Inter‐ORB Protocol 
(IIOP). IIOP transactions can take place over TCP streams, or via other protocols (such as HTTP), 

254 
 
 
in the event that a client or server is behind a firewall. The following diagram shows a client and 
a servant communicating. 

   

CORBA client sends a request through its local CORBA  servant  sends  back  a  response  to  a 


ORB to a remote ORB's servant  remote ORB 

Limitations of CORBA  

Describing  services  require  the  use  of  an  interface  definition  language  (IDL)  which  must  be 
learned.  Implementing  or  using  services  require  an  IDL  mapping  to  your  required  language  ‐ 
writing one for a language that isn't supported would take a large amount of work. 

IDL to language mapping tools create code stubs based on the interface ‐ some tools may not 
integrate new changes with existing code. 

CORBA does not support the transfer of objects, or code. 

The future is uncertain ‐ if CORBA fails to achieve sufficient adoption by industry, then CORBA 
implementations become the legacy systems. 

Some training is still required, and CORBA specifications are still in a state of flux 

Not all classes of applications need real‐time performance, and speed may be traded off against 
ease of use for pure Java systems. 

Service‐Oriented  Architectures  are  an  approach  to  distributed  computing  that  thinks  of 
software  resources  as  services  available  on  a  network.  Such  architectures  are  nothing  new; 
CORBA and DCOM are familiar examples. However, these older examples of service‐orientation 
suffered from a few difficult problems. First, they were tightly coupled, which meant that both 
ends of each distributed computing link had to agree on the details of the API. A code change 
to  a  COM  object,  for  example,  required  corresponding  changes  to  the  code  accessing  that 
object. Secondly, such Service‐Oriented Architectures were proprietary. Microsoft unabashedly 
controlled  DCOM,  and  while  CORBA  was  ostensibly  a  standards‐based  effort,  in  practice, 
implementing  a  CORBA  architecture  typically  necessitated  the  decision  to  work  with  a  single 
vendor's implementation of the specification. 

255 
 
 
Web  services  is  an  evolutionary  development  that  improves  upon  DCOM  and  CORBA's 
weaknesses. What is new about today's Service‐Oriented Architectures built with Web services 
is  that  they  are  standards‐based  and  loosely  coupled.  The  reliance  upon  universally  accepted 
standards  like  XML  and  SOAP  provides  broad  interoperability  among  different  vendors' 
solutions,  and  loose  coupling  separates  the  participants  in  distributed  computing  interactions 
so  that  modifying  the  interface  of  one  participant  in  the  exchange  does  not  break  the  other. 
The  combination  of  these  two  core  principles  means  that  companies  can  implement  Web 
services without having any knowledge of the consumers of those services, and vice versa. The 
Service‐Oriented  Architectures  we  will  discuss  are  the  standards‐based,  loosely  coupled  kind, 
which we will refer to as SOAs. 

CORBA and DCOM: A Feature Comparison 
In the following sections, we define each “enterprise” quality and compare the levels of support 
currently 
available  in  CORBA  and  DCOM  specifications  and  products.  Although  this  list  is  not 
comprehensive, it 
stands as a reasonable baseline for middleware comparison. These features are not necessarily 
listed in 
order  of  priority.  Instead,  each  is  treated  independently,  though  many  are  highly 
interdependent. Finally, 
individual  ratings  are  given  at  the  end  of  each  section  to  indicate  the  relative  levels  of 
enterprise readiness. 
A “+” implies full readiness, “0” connotes marginal status, and “‐” indicates a failure to meet the 
overall 
needs of the enterprise. 
Interoperability 
 
Cross‐Language Support 
Cross‐language  support  is  one  part  of  the  critical  interoperability  capabilities  required  of 
enterprise systems. While languages such as C++, Visual Basic, and Java are on the rise, COBOL 
is  still  often  cited  as  the  most  widely  used  programming  language,  with  an  estimated  three 
million active programmers.  
CORBA 
CORBA  was  designed  from  the  ground  up  to  be  language  and  platform  independent  through 
the  use  of  a  common  Interface  Definition  Language  (IDL).  Now  an  ISO  standard,  OMG  IDL 
provides a common notation for describing cross‐platform, cross‐language application program 
interfaces  (APIs).  IDL  is  used  to  define  the  “interface”  of  the  component,  not  the  inner 
workings. 
For  this,  other  standard  programming  languages  are  used.  IDL  interfaces  are  translated  to 
standard  languages  through  mappings.  Currently,  IDL  has  been  mapped  to  C,  C++,  Smalltalk, 
Ada, OLE (Visual Basic, PowerBuilder, Delphi, etc.), Java, and soon to Eiffel and Objective C. The 
benefits of interoperability are not without costs however. IDL was never meant to substitute 
for a general‐purpose language. Instead, it was designed to express generalized interfaces. IDL 
limits  the  language  data  types  to  a  least  common  denominator  that  can  be  supported  by  all 
256 
 
 
languages. Although some of the language‐specific data types are not directly usable, IDL does 
permit an “any” type to overcome this obstacle. 
DCOM 
DCOM’s  language  portability  (heterogeneity)  is  based  upon  a  “binary  standard.”  Binary 
compatibility is accomplished at the ones‐and‐zeros level, an area that has previously been the 
domain  of  computer  language  compilers  and  interpreters.  To  guarantee  compatibility  at  this 
level, the way each language is translated to machine binary code must be controlled. This can 
present  a  few  obstacles,  but  also  has  its  benefits.  First,  there  are  fundamental  differences  in 
how languages are translated. Since some languages are compiled and others are interpreted, 
“binary  compatibility”  requires  that  components  support  all  possible  translation  variations. 
Second,  there  are  many  compilers/interpreters  for  a  given  language,  each  taking  unique 
approaches  to  code  translation.  Finally,  specifying  compatibility  at  such  a  low  hardware  level 
creates vulnerabilities due to advances in hardware itself. 
Microsoft has been successful in controlling the mainstream development tools in the desktop 
arena  for  DCOM’s  predecessor,  COM.  COM  is  currently  supported  by  the  popular  array  of 
Microsoft products as well as Java, PowerBuilder, Delphi, and Micro Focus COBOL. Distributed 
COM,  however,  requires  additional  support  from  Microsoft  or  a  third  party  that  ports  DCOM 
(see Software AG below). 
Summary:  Both  CORBA  and  DCOM  provide  extensive  support  for  multiple  programming 
languages, though they use different techniques. 
META Group Consulting  
Enterprise Criterion Ratings 
Interoperability CORBA DCOM 
Cross‐Language Support + + 
Cross‐Platform Support 
The  “middle”  in  middleware  often  refers  to  the  synergistic  connection  between  disparate 
enterprise IT resources. Until it is feasible for all enterprise resources to be hosted entirely on 
homogenous hardware platforms, middleware must support new and legacy platforms and the 
freedom to mix them as required. 
CORBA 
Cross‐platform  support  has  always  been  a  central  focus  of  CORBA.  ORBs  currently  exist  for 
more  than  30  platforms  and  supports  even  more  Microsoft  operating  systems  than  DCOM. 
Orbix, one of the leading ORB products, supports 20 platforms itself. 
DCOM 
DCOM  has  approached  cross‐platform  support  as  an  afterthought.  In  1993,  Microsoft 
approached a German company, Software AG, to port DCOM to other platforms. Software AG 
has  ported  DCOM  to  several  Unix  variants;  however,  the  port  does  not  include  many  of  the 
components  of  DCOM.  For  example,  many  critical  supporting  technologies  have  not  been 
ported, the most important of which are MTS and MSMQ. Without MTS and MSMQ, DCOM is 
simply  not  a  viable  enterprise  middleware.  DCOM  has  also  been  ported  to  Macintoshes  and 
DEC  Alphas  that  run  Windows  NT.  Many  other  ports  are  currently  in  the  works  (Open  VMS, 
Digital Unix, HPUX, Solaris, IBM OS/390, IBM AIX, and Linux). 
Summary: It should be clear by now that in order to cast either of these technologies into the 
enterprise  role,  a  comprehensive  collection  of  critical  infrastructure  services  must  be 
considered for each of the required platforms. For DCOM, this means exploiting the combined 
synergies of COM, MTS, MSMQ, and clustering them together to fulfill the needs of enterprise 
257 
 
 
computing.  Without MTS, for example, DCOM will be unable to fulfill these needs. By way of 
comparison,  CORBA‐based  products  typically  provide  each  of  their  services  on  all  supported 
platforms. As such, ORBs are much further ahead in their support for heterogeneous enterprise 
environments. Enterprise Criterion Ratings 
Interoperability CORBA DCOM Cross‐Platform Support + ‐ 
Network Communications 
Robust  support  for  enterprise  network  communications  requires  that  middleware  seamlessly 
provide  interoperability  with  many  disparate  networked  systems.  To  enable  this,  the 
middleware should be “protocol transparent.” 
CORBA 
The predominant CORBA networking model for cross‐ORB communication is based on a form of 
TCP  known  as  IIOP  (Internet  Inter‐ORB  Protocol),  a  connection‐based  protocol.  IIOP  was 
specifically designed to ensure that all ORBs use a common communications protocol. Internal 
to a particular ORB, however, other protocols are possible. ORB products, similar to DCOM, are 
usually remote procedure call (RPC)‐based. 
META Group Consulting 9 
DCOM 
Initially, DCOM utilized UDP/DCOM, a connectionless protocol that is based on the OSF’s DCE 
RPC  specification  with  some  changes.  DCOM  now  offers  a  TCP  protocol  configuration  as  an 
option, although by using this, many efficiency features are sacrificed.  
 Summary: CORBA has established the lead in common network protocol support through the 
de facto IIOP standard. DCOM provides protocol options, but does not support them equally. 
Enterprise Criterion Ratings Interoperability CORBA DCOM 
Network Communications + 0 
Common Services 
Common services form the base infrastructure of the middleware. These services are married 
to the individual patterns of business in an enterprise setting. For example, a banking model is 
highly  transaction  oriented  and  requires  secure  transaction  support  as  a  fundamental 
middleware service. To this end, most organizations require a number of key services. It should 
be understood, however, that not all services are equally important to all enterprises. Where 
more  than  one  service  is  required,  it  should  be  fully  compatible  and  interoperable  with  the 
others.  Using  the  OMG  specification  terminology,  we  consider  the  following  services  as  a 
minimal  set  for  enterprise  middleware:  Transactions,  Directory,  Messaging,  Security,  and 
interoperability.  The  CORBA  road  map  provides  ORB  vendors  with  a  path  for  service 
interoperability.  This  interoperability  is  required  to  integrate  the  best  available  third‐party 
services  across  platforms.  Microsoft’s  approach  is  less  explicit,  with  service  interoperability 
implied  for  the  NT  platform  only.  CORBA  and  DCOM  products  support  these  basic  services  in 
various degrees. 
CORBA 
The OMG has concentrated on the development and integration of key architectural services. 
Their  technology  adoption  process  is  specifically  aimed  at  ensuring  that  services  are 
implemented in an interoperable manner. The CORBA specification defines 15 services, though 
not all commercial ORB products support the complete set. One exception to this is IBM’s COS 
(Common Object Services), a suite of the full 15 CORBA services that is compatible with DSOM 
and other brokers. 
DCOM 
258 
 
 
DCOM  services  are  less  defined  from  an  architectural  standpoint,  though  there  are  many 
CORBA equivalents. DCOM currently offers a limited naming service, transactions, and security 
integration with NT. Other services such as MSMQ and clustering are becoming available, but 
are not formally integrated into the DCOM specification. 
Summary: Full‐service support is not yet available from DCOM or CORBA products. At present, 
CORBA  products  have  the  lead  in  the  number,  maturity,  and  scope  of  enterprise‐required 
services  that  are  made  available  to  both  new  and  legacy  applications.  Enterprise  Criterion 
Ratings 
Interoperability CORBA DCOM 
Common Services 0 ‐ 
META Group Consulting 10 
Reliability 
Transactions 
Transaction  support  has  been  the  focus  of  both  middleware  technologies  in  recent  years. 
During 1997, the gaps in both camps were significantly closed.  
CORBA 
CORBA’s Object Transaction Service (OTS) specification offers a range of services for distributed 
transaction support. These services extend the range of traditional flat transactions to support 
both  flat  and  nested  transactions  (since  nested  transactions  break  up  transactions  into 
hierarchies  of  sub‐transactions,  this  offers  developers  the  flexibility  for  failures  in  a 
subtransaction  to  be  retried  using  an  alternative  method,  while  the  main  transaction  can 
succeed). 
OTS enables both ORB and non‐ORB applications to participate in the same transaction, so that 
object  transactions  and  procedural  transactions  (that  support  X/Open’s  DTP  standard)  can 
interoperate.  It  also  supports  transactions  across  heterogeneous  ORBs,  so  that  multiple  ORBs 
can participate in the same transaction. Also, a single IDL interface supports both transactional 
and  non‐transactional  implementations.  To  make  an  object  transactional,  developers  use  an 
interface that inherits from an abstract OTS class. Taken together, the interfaces for OTS, plus 
the Concurrency and Control service and Transactions, offer full commit, rollback, locking and 
other  capabilities,  enabling  ORB  vendors  supporting  it  to  offer  distributed  transaction 
capabilities. A number of the ORB implementers have offered links to tools from traditional TP 
monitors,  and  OTS  enables  them  to  incorporate  these  capabilities  directly  into  the  ORB  and 
distribute them. 
The goal of integrating best‐of‐breed transaction products has been widely realized in the ORB 
marketplace  over  the  last  year.  Tuxedo,  the  most  scalable  TP  monitor  for  highly  distributed 
environments, has been successfully integrated with two prominent ORBs. In addition, Visigenic 
and Hitachi have integrated TPBroker and Iona has integrated Transarc in OrbixOTS. 
DCOM 
Microsoft also has been aggressively attacking transaction support in the form of its Microsoft 
Transaction Server (MTS). As a fully integrated transaction service, MTS has great potential for 
at least the Wintel environment, and is positioned by Microsoft as an extension to DCOM. With 
MTS, transactions are supported implicitly, thereby freeing the developer from the complexity 
of dealing with transaction services directly. This enables MTS to preserve the 
component model.  In addition, MTS provides a declarative security model. MTS is in an early 
state of maturity, however. Few examples are available to assess the relative scalability of MTS, 
and it has not been offered for the cross‐platform environment to date. 
259 
 
 
Summary:  We  continue  to  believe  that  CORBA  will  remain  the  leading‐edge  middleware 
transaction model for networked objects, with DCOM MTS transaction support suitable for low‐
end processing but gaining ground quickly. 
Enterprise Criterion Ratings 
Reliability CORBA DCOM 
Transactions + 0 
Messaging 
Reliable  transmission  and  receipt  of  messages  is  a  foundational  quality  of  distributed 
middleware. Without it, the electronic commerce (EC) systems of tomorrow will ultimately fail 
in  delivering  expedient  and  reliable  services  to  the  increasingly  demanding  marketplace. 
Effective  messaging  requires  four  important  qualities:  reliability,  user  convenience,  system 
convenience, and performance.  
META Group Consulting 11 
In messaging, reliability means nothing less than guaranteed delivery. To guarantee delivery of 
anything  requires  a  reliable  middleman,  not  unlike  the  US  Postal  Service.  Rain  or  shine,  the 
postal  service  can  be  relied  upon  to  deliver  mail  to  its  eventual  destination.  The  operational 
word here is “eventual.” If the weather becomes too severe, postal workers do not throw the 
mail away; they hold onto it until the weather permits delivery. The same quality is required of 
middleware. 
User convenience, system convenience, and performance are highly interrelated qualities. User 
convenience means that the sending and receiving parties are not forced to be at a particular 
place and time to send and receive messages. This is known in technical terms as asynchronous 
communication. With asynchronous communication, a sender or system does not have to wait 
until the message is sent AND received before being able to do other work. This convenience 
enables  all  parties  —  sender,  system,  and  receiver  —  to  continue  performing  useful  work, 
regardless  of  each  other’s  current  situation.  To  support  these  needs,  distributed  middleware 
requires a robust message queuing system. Message 
queues support asynchronous transmission by providing a persistent queue (message queue) as 
a temporary message holding area. Again, CORBA and DCOM approach messaging in different 
ways, but both technologies are geared toward the same needs outlined above. 
CORBA 
The  early  CORBA  specifications  addressed  messaging  from  a  more  primitive  standpoint.  The 
Event Service was the basis of many messaging protocols such as push‐pull and pull‐push. ORBs 
typically  provided  two  avenues  for  messaging:  the  Event  Service  primitives  or  a  proprietary 
mechanism.  The  OMG  recently  addressed  a  more  robust  messaging  model  in  the 
CORBAservices  specification.  This  specification  addresses  the  asynchronous  communication 
option that is required by enterprise‐grade applications; however, it has not been adopted yet. 
Many  ORB  products  have  implemented  extensions  to  the  CORBA  Events  service  that  provide 
reliable  messaging.  For  example,  in  early  1996,  Orbix  announced  their  OrbixTalk  Reliable 
Multicast  Protocol,  which  provides  reliable  sequencing  and  delivery  of  messages.  Some  ORB 
implementations  have  integrated  an  enterprise‐grade  messaging  service  on  par  with 
standalone Message‐Oriented Middleware (MOM). IBM’s ComponentBroker is one example of 
integration with MQSeries, a leading MOM product. Iona has been successful in demonstrating 
GIOP  over  MQSeries.  BEA  has  also  announced  intentions  to  integrate  its  newly  acquired 
MessageQ into the Iceberg product. 
DCOM 
260 
 
 
Formally, DCOM does not directly support asynchronous communication. Microsoft’s answer to 
reliable  messaging  is  a  separate  offering  titled  Microsoft  Message  Queue  Server  (MSMQ)  or 
Falcon. On the plus side, MSMQ promises to support each of the important qualities of reliable 
messaging and more. Unfortunately, MSMQ is not a fully integrated part of DCOM at this time 
and has the same interoperability limitations as MTS.  Software AG’s EntireX product, a cross‐
platform port of DCOM, is integrated with the proprietary EntireX Message Broker service. This 
service  does  not  rely  upon  MSMG  and  provides  persistent  storage  of  messages  to  enable 
asynchronous communication between clients and servers. 
Summary: Reliable messaging is now being recognized by both CORBA and DCOM as a critical 
service  for  the  enterprise.  CORBA  has  been  augmented  with  leading  MOM  products,  but  full 
inter‐service integration has not yet been achieved. DCOM has also been augmented with early 
MOM  functionality,  but  also  lacks  full  integration  with  other  complementary  services  and  is 
again, not available across a wide range of platforms. Enterprise Criterion Ratings 
Reliability CORBA DCOMMessaging 0 ‐ 
META Group Consulting 12 
Security 
Clearly, security is one of the key considerations for enterprise computing. Most organizations 
cringe  at  the  prospect  of  opening  up  the  mainframe  to  the  Internet.  Distributed  applications 
that are exposed to the Web simply cannot tolerate security breaches. 
CORBA 
The CORBA Security service is one of the most comprehensive security specifications available 
for  distributed  computing.  The  262‐page  specification  was  jointly  adopted  with  the  Time 
Service  and  covers  nearly  every  conceivable  aspect  of  security,  including  integrity, 
accountability, availability, confidentiality, and non‐repudiation. It also recognizes that differing 
levels  of  security  needs  exist  in  an  enterprise  environment.  The  service  defines  three  (0‐2) 
levels of security compliance, ranging from non‐aware ORB products to those that require the 
entire  range  of  services  (access  control,  delegation,  auditing,  authentication,  and  policy 
implementation). 
ORB  products  differ  widely  in  their  support  for  security.  For  example,  ICL’s  DAIS  product  was 
the first ORB to offer CORBA security conforming to Kerberos and the GSS API standards. Orbix 
provides both the SSL‐IIOP standard (secure encrypted communications over the Internet) and 
an  implementation  of  the  CORBA  Security  Level  1  service.  Finally,  Visigenic  has  recently 
partnered with MITRE Corporation spin‐off Concept Five to deliver the first ORB complying with 
CORBA Level 2 security. 
DCOM 
DCOM  utilizes  NT  mechanisms  as  the  basis  of  its  security  support.  NT  Version  3.5  has  been 
rated level C2 by the National Computer Security Center and ensures a comprehensive array of 
security  controls  such  as  discretionary  access,  authentication,  and  auditing.  DCOM  also 
provides  a CryptoAPI  to  enable  advanced encryption  of  information.  This  service  requires  the 
support of a Cryptographic Service Provider (CSP) that is provided with NT. Without question, 
the  combination  of  NT,  MTS,  and  COM  can  provide  a  comprehensively  secure  environment; 
however,  because  DCOM’s  security  managers  are  NT  dependent,  this  support  is  limited  to 
Windows/NT platforms. 
Summary:  CORBA  and  DCOM  are  both  building  comprehensive  security  mechanisms.  To 
CORBA’s credit, the recognition of a wide variety of security services will provide more solutions 
to the differing needs of the enterprise. For DCOM, the cooperation of the operating system is 
261 
 
 
paramount  to  providing  high  levels  of  security.  Although  from  different  directions,  both 
middleware  technologies  are  reaching  critical  mass  in  their  support  for  secure  distributed 
computing. Enterprise Criterion Ratings 
Reliability CORBA DCOM 
Security 0 0 
Directory Service 
An essential feature of any middleware is the ability to keep track of the location of key services 
in the distributed network space. This lessens the burden of each application (provides location 
transparency)  and,  more  importantly,  provides  for  load  balancing  and  failover  services. 
Examples of working directory services include; DNS, X.500, Novell NDS, and Microsoft NTDS, 
though each is accessed by a specialized interface. 
META Group Consulting 13 
CORBA 
The  OMG  has  specified  the  Naming  Service  for  just  this  purpose.  Similar  to  a  “white  pages” 
directory, the Naming Service permits a component to look up a service by name. The Naming 
Service  was  designed  to  allow  the  use  of  conventional  directory  services  such  as  those 
identified  above.  These  services  are  wrapped  by  a  higher‐level  service  interface  that  masks 
idiosyncrasies from the developer. 
VisiBroker offers a CORBA‐compliant naming service that is fault tolerant (self‐recovering) and 
persistent  (survives  shutdowns  and  abnormal  failures),  and  supports  federated  name  spaces. 
Orbix also provides a fault‐tolerant naming service. 
DCOM 
Microsoft’s answer to this need is called the Active Directory Service (ADS). This service is said 
to combine the best features of X.500 and DNS. Like the OMG Naming Service, ADS intends to 
abstract  differences  between  various  directory  services  by  providing  one  standardized 
interface. ADS Version 1.0 is offered with NT 4.0, with the full ADS capability to be integrated in 
NT  5.0.  The  ADS  Interface  (ADSI)  is  based  on  DCOM  with  specific  offerings  from  directory 
service providers being implemented as DCOM objects. 
Summary: Both CORBA and DCOM are beginning to support sophisticated directory services on 
par  with  previous  “enterprise  tested”  incarnations  such  as  NDS  and  DNS.  Enterprise  Criterion 
Ratings 
Reliability CORBA DCOM 
Directory Service 0 0 
Fault Tolerance 
Middleware’s  ability  to  “heal  itself”  in  the  event  of  reasonable  failure  is  essential  for  most 
enterprise  applications.  There  are  many  supporting  mechanisms  that  contribute  to  this 
capability. Asynchronous messaging (discussed under Messaging) is one example. Service pools 
and  redundant  failover  mechanisms  also  enable  graceful  recovery  and  increase  the  fault 
tolerance and reliability of middleware. Finally, a reliable directory service is needed to find and 
connect backup services in the event of failure. 
CORBA 
The CORBA specification does not directly support fault‐tolerance services; however, many ORB 
vendors  have  provided  this  support.  For  example,  Visigenic’s  VisiBroker  provides  symmetric 
failover support to automatically bind to another object server on a separate host in the event 
of service failure. 

262 
 
 
Most  ORBs  provide  a  simple  timeout  mechanism  for  detecting  dead  or  disconnected  clients. 
This approach alone is not sufficient for highly fault‐tolerant applications. 
DCOM 
Basic  support  for  fault  tolerance  is  provided  at  the  protocol  level.  DCOM  utilizes  reference 
counts augmented by “keep alive” messages or pinging as an essential component of the DCOM 
object  life  cycle.  It  requires  the  successful  transmission  and  receipt  of  a  heartbeat  every  two 
minutes  between  a  client  and  server.  If  three  consecutive  heartbeats  are  missed,  the  server 
declares the client dead and decrements the reference count. According to a recent Web FAQ1 
maintained by AT&T Labs (updated Nov. 5, 1997), DCOM does not support configurable times, 
so clients may not detect problems for a considerable period of time (six minutes). Further, if a 
distributed  component  gets  into  a  continuous  loop,  there  is  no  automated  way  to  detect  a 
problem,  because  the  1  COM  Reliability  FAQ; 
http://akpublic.research.att.com/~ymwang/resources/COM‐R‐FAQ.htm  
 
META Group Consulting 14 
heartbeats will still be sent. Finally, this approach utilizes significant network resources and may 
not  scale  well  for  large  numbers  of  connections.  Microsoft  has  taken  positive  steps  to 
streamline this approach and has employed piggybacking, grouped pings, and delta pinging to 
reduce  network  traffic.  Anything  beyond  this  generally  requires  extensive  customization  on 
both the middleware and application side. 
Summary:  Both  DCOM  and  CORBA  do  not  directly  support  robust  fault  tolerance;  however, 
with  sophisticated  customization,  it  can  be  provided.  For  DCOM,  it  is  not  clear  whether  such 
customization  is  possible  across  a  heterogeneous  platform  environment,  because  most 
workarounds  currently  require  the  support  of  NT  or  Windows  95  components.Enterprise 
Criterion Ratings 
Reliability CORBA DCOM 
Fault Tolerance 0 0 
Performance 
Scalability 
We  generally  define  scalability  as  the  middleware’s  ability  to  perform  when  the  size  of  the 
problem  increases.  Middleware  performance  can  be  highly  variable  depending  on  how  it  is 
used. For example, component granularity is one of the most significant drivers of performance 
stress.  In  other  words,  as  the  pieces  get  smaller,  so  does  sheer  volume  —  causing  the 
middleware  substrate  mechanisms  to  work  harder.  As  this  occurs,  the  need  arises  for 
middleware  mechanism  tuning  in  ways  that  conventional  database  products  have  supported. 
Finally,  middleware  performance  is  very  costly  to  measure,  since  only  in  vitro  modeling  can 
provide a reasonable capacity estimation. 
There  must  be  compelling  evidence,  via  current  implementations  or  anecdotal  data,  that 
indicate  the  middleware’s  ability  to  scale  through  various  scenarios.  These  scenarios  may 
include  numbers  of  objects  or  users.  Key  areas  where  impacts  are  most  likely  are  found  in 
services  that  commonly  aggregate  components  such  as  naming  services  or  interface 
repositories.  Finally,  middleware  must  able  to  support  threads  to  allow  parallel  processing  of 
work. 
CORBA 

263 
 
 
As a specification, CORBA does not address specific scalability services aside from providing for 
the  transparent  distribution  of  processing.  Instead,  individual  ORBs  deal  with  this  problem  in 
one of two ways: 
Threading — Many ORBs provide thread‐safe libraries that use each operating system’s native 
thread model. This enables threads to be created for clients, objects, or even specific method 
calls of an object. In addition, several ORB products also support thread pools. Filters can also 
be used to balance processing based on current loading. 
Tuning — ORB products provide various internal tuning mechanisms to enable optimization for 
specific  situations.  For  example,  internal  memory  representations  can  be  changed  to  order 
references by “most frequently used” or other criteria that suit the specific conditions. 
DCOM 
DCOM offers similar scalability mechanisms such as parallel processing and threading. As with 
CORBA,  DCOM  features  are  not  transparently  supported,  and  require  detailed  knowledge  of 
client/server interactions to implement. 
META Group Consulting 15 
Thread pools — DCOM utilizes thread pool managers to maximize scalability however, Windows 
NT symmetric multiprocessing is required to support this feature. Summary: Both middleware 
products  are  relatively  nascent  in  their  support  for  highly  scalable  enterprise  applications. 
There  are,  however,  a  growing  number  of  large‐scale  ORB  implementation  examples  in  the 
investment,  aerospace,  and  telecommunications  industries.  In  addition,  indirect  evidence  of 
scalability  can  be  inferred  when  combining  ORBs  with  enterprise‐grade  products  such  as 
commercial  TP  monitors  and  MOM.  Concrete  evidence  of  large‐scale  DCOM  enterprise 
applications is not readily available at this time. Enterprise Criterion Ratings 
Performance CORBA DCOM 
Scalability 0 ‐ 
Viability 
Product Maturity 
Despite the current fragmented condition of middleware offerings, we believe IT organizations 
should  be  consumers  of  middleware  components,  not  producers.  As  of  this  writing,  the  best 
way  to  manage  the  massive  complexity  of  middleware  is  through  the  purchase  and 
customization  of  commercial  frameworks  that  organize  their  flexibility  into  structured 
application  packages.  Such  frameworks  go  beyond  the  primitive  and  complex  services  that 
CORBA and DCOM can provide but still require a minimum maturity level from each. 
CORBA 
Many commercial ORB products are in their third generation of development. As such, we are 
beginning to see a critical mass of services (Directory, Messaging, Transactions, and Security) in 
several leading products. Although the OMG specification is explicitly designed to insure these 
services  are  well  integrated,  no  single  ORB  vendor  has  brought  them  all  together  in  strict 
CORBA  compliance.  Irrespective  of  this,  ORBs  are  now  being  used  for  enterprise  systems  in 
many demanding industries, including telecommunications, aerospace, and investment. 
DCOM 
The arrival of the predator services (Falcon, Viper, Wolfpack, and Active Directory) represents 
Microsoft’s recognition of what must be in place in an enterprise setting. Like the leading ORB 
products, these services are not fully integrated (even in the “NT only” environment) and are 
not explicitly part of DCOM. What is worse, platform interoperability is only just appearing on 
the DCOM radar screen and will likely be the last piece to fall into place. 
264 
 
 
Summary: Products from both DCOM and CORBA are only just beginning to aspire to the so‐
called “heavy lifting” demands of the enterprise. At the end of the day, representative products 
from both middleware camps require a tremendous amount of financial fortitude and technical 
expertise from the adopting enterprise to be successful. 
Enterprise Criterion Ratings 
Viability CORBA DCOM 
Product Maturity 0 ‐ 
Vendor Outlook 
Clearly, the trick is to buy and extend frameworks that are based on the likely winners of the 
middleware framework wars, not the losers. 
META Group Consulting 16 
CORBA 
CORBA differs from DCOM in an important way. While the CORBA specification is controlled by 
the OMG standards body, ORBs are produced by a variety of vendors (though most belong to 
the OMG).  This separation has caused — and  always will cause — a natural tension between 
the  need  to  differentiate  product  offerings  and  the  need  for  interoperable  standards 
compliance. The OMG currently enjoys membership and backing from some 760 members. This 
large  membership  will  continue  to  uphold  the  OMG’s  emphasis  on  interoperable  and 
standardized solutions but is 
often to blame for slow progress. 
There  are  several  leading  vendors  whose  viability  is  sound  for  at  least  the  next  several 
generations of enterprise technology. Users must insist on enterprise players that will not only 
survive  the  middleware  wars  but  also  remain  committed  to  ORBs  as  part  of  their  long‐term, 
strategic direction. Such vendors as IBM, BEA, and Orbix appear to fit this category. 
DCOM 
Clearly, Microsoft will be one of the survivors. Microsoft stands as testament to the difference 
between  technological  elegance  and  marketing  leadership,  a  distinction  that  should  never  be 
overlooked.  While  there  is  no  question  about  Microsoft’s  intention  to  support  its  value 
proposition  —  optimized  product  integration  on  lower‐cost  NT  platforms  —  overwhelming 
support for competing platforms would not be a logical assumption. That being said, Microsoft 
will  continue  to  focus  its  attentions  on  real  scalability,  manageability,  and  low  cost  in  the  NT 
environment. 
Summary:  Both  technologies  will  continue  to  have  significant  market  backing  and  support. 
DCOM will continue to enjoy heavy independent software vendor (ISV) tool support while ORBs 
will  continue  to  be  supported  by  corporate  customers.  It  is  important  to  note,  however,  that 
non‐DCOM integrated services such as MTS and MSMQ have not been widely tested, and ISV 
acceptance for these is yet to be determined. Enterprise Criterion Ratings 
Viability CORBA DCOM 
Vendor Outlook + + 
 

Web service technology stack 

WEB SERVICES TECHNOLOGIES stack 

Web Service Technology Stack 

265 
 
 

 
 

  Discovery: fetch descriptions of providers. UDDI, WS‐Inspection. 

  Description: describe services. WSDL. 

  Packaging: is serialization or marshaling. SOAP. 

  Transport: application‐to‐application   communication. HTTP, SMTP, TCP, Jabber. 

 Network: network layer. TCP/IP 

Communications Layer 

Web Services are essentially transport‐neutral. 

A  web  service  message  can  be  transported  using  HTTP  or  HTTPS,  as  well  as  more 
specialized transport mechanisms, such as e.g. JMS.Web services insulate the designer 
from most of the details and implications of the message transport layer.   

Messaging Layer 

SOAP = Simple Object Access Protocol 

A protocol to exchange structured information in a distributed environment.  

SOAP extensions:  

266 
 
 
1)  WS‐Reliable  Messaging  ‐  a  standard  for  web  services  messaging  to  guarantee  the 
receipt of messages for WS requestors and providers 

2)  WS‐Transactions  ‐  a  series  of  standards  related  to  WS  invocations  in  transactions 
(atomicity, consistency, isolation and durability semantics) 

Descriptions Layer 

WSDL = Web Services Description Language 

A  language  that  allows  a  service  provider  to  specify  the  functional  characteristic  of  its 
web services.   

WSDL extensions: 

1) WS‐Policy ‐ augment WSDL with non‐functional constraints on WS 

2) WS‐Resource Properties – describes how to define and access properties of resources 
through WS 

Processes Layer: Discovery 

Discovery ‐ locating a machine‐processable description of a web service that may have 
been previously unknown and that meets certain criteria. 

UDDI = Universal Description, Discovery and Integration   

UDDI defines a way to store and retrieve information about web services. 

Processes Layer: Choreography 

Choreography  ‐  defines  how  multiple  cooperating  independent  agents  exchange 


messages in order to perform a task to achieve a given goal.  

WS‐CDL  =  WS  Choreography  Description  Language.WS‐CDL  describes  peer‐to‐peer 


collaborations  where  ordered  message  exchanges  result  in  accomplishing  a  common 
business goal. 

WS Interoperability 

Web  Services  tackle  the  set  of  problems  related  to  loosely  coupled  dynamically 
configured heterogeneous distributed computing. 

WS Specifications: 

1)  A  series  of  smaller,  purpose‐focused  specifications  dealing  with  narrow  problems 
(security, transactions, etc.) in isolation.  

267 
 
 
2) Each WS specification is designed to be composed with the others. 

3)  WS  designers  determine  which  specifications  their  system  needs  and  implement 
them accordingly. 

WS‐I Organization 

Web Services Interoperability organization (WS‐I):  

1) WS‐I is to standardize combinations of WS specifications that can be used to increase 
the level of interoperability between web services. 

2) WS‐I promotes the Basic Profile ‐ implementation guidelines for how non‐proprietary 
WS  specifications,  such  as  SOAP,  WSDL,  UDDI,  should  be  used  together  for  best 
interoperability. 

268 
 
 

Current Web services stack 

In this section, I will recap the standards and the tools used to implement them at each layer in 
the Web services stack. We start from the bottommost layer, transport, and work my way up 
one layer at a time until I reach the final layer, service flow. 

Transport layer 

As you can see in Figure 2, the transport layer is the foundation of the Web services stack. Web 
services  must  be  invoked  by  a  service  client  so  they  can  be  accessible  to  a  network.  Web 
services that are publicly available run over the Internet. Only the authorized users within an 
internal organization can view intranet‐available Web services, while unauthorized users in the 
outside world cannot. It is possible to create extranet‐based Web services to allow legitimate 
users access to them on more than one intranet. 

269 
 
 
 
Figure  2.  Original  Web  services  stack 

The  Internet  protocols  that  can  be  supported  by  this  stack  are  HTTP  and,  to  a  lesser  extent, 
SMTP  (for  electronic  mail)  and  FTP  (for  file  transfer).  Intranet  domains  use  middleware  call 
infrastructures,  such  as  IBM's  MQSeries,  and  CORBA  (the  Common  Object  Request  Broker 
Architecture).  The  latter  relies  on  a  protocol  called  the  Internet  Inter‐ORB  Protocol  (IIOP)  for 
remote objects. 

MQSeries name changes 

Note that the following MQSeries products have been renamed as part of the consolidation of 
IBM's middleware product portfolio:  

• MQSeries has been renamed WebSphere MQ. 
• MQSeries Integrator has been renamed WebSphere MQ Integrator. 
• WS BtoBi PAM has been renamed WebSphere Partner Agreement Manager. 

XML‐based messaging layer 

In this layer, SOAP is the messaging protocol for XML. It is built upon the lower layer ‐‐ transport 
‐‐  meaning that  SOAP  is  used  singly  or  in  combination  with  any  transport  protocols.  All  SOAP 
messages support the publish, bind, and find operations in the Web services architecture. SOAP 
comprises  three  parts:  an  envelope  to  describe  the  content  of  a  message,  a  set  of  encoding 
rules, and a mechanism for providing remote procedure calls (RPCs) and responses.  

IBM,  Microsoft,  and  others  submitted  SOAP  to  the  W3C  as  the  basis  of  the  XML  Protocol 
Working  Group.  When  the  W3C  releases  a  draft  standard  for  the  XML  protocol,  the  Web 
services architecture stack will migrate from SOAP to the XML protocol.  

Service description layer 

Service  description  provides  the  means  of  invoking  Web  services.  WSDL  is  the  basic  standard 
for  defining,  in  XML  format,  the  implementations  and  interfaces  of  services.  This  means  that 
270 
 
 
WSDL divides a service description into two parts: service implementation and service interface. 
You must create a service interface before you can implement WSDL.  

Service publication layer 

You  need other service description documents to complement WSDL.  You can use UDDI data 


structures to describe business context, for example. You can make a WSDL document available 
to  a  service  client  at  any  stage  of  the  service  client's  life  cycle.  When  this  happens,  the  stack 
moves up to the next layer, service publication. At this layer, the service provider can send a 
WSDL  document  directly  to  a  service  client  via  e‐mail,  for  example.  This  action  is  known  as 
direct  publication.  The  service  provider  can  also  choose  to  publish  the  WSDL  document  to  a 
host‐local WSDL registry, or to a public or private UDDI registry. IBM's WSCA specifies how the 
definitions for two components of WSDL can be derived from the UDDI entries.  

Service discovery layer 

Service discovery relies on service publication; if a Web service is not or cannot be published, it 
cannot be found or discovered. The service client can make the service description available to 
an application at runtime. The service client, for example, can retrieve a WSDL document from 
a  local  file  obtained  through  a  direct  publish.  This  action  is  known  as  static  discovery.  The 
service  can  also  be  discovered  at  design  or  run  time  using  either  a  local  WSDL  registry  or  a 
public or private UDDI registry.  

Service flow layer 

Web Services Flow Language (WSFL) is the standard for the service flow layer at the top of the 
stack. It differs from other standards in the stack in that it looks at business process modeling 
and  workflows.  WSFL  is  used  to  describe  how  Web  services  are  to  interact  in  workflows  and 
how  they  are  to  perform  in  service‐to‐service  communications  or  collaborations.  This  means 
that  Web  services  are  components  of,  or  can  be  dynamically  orchestrated  into,  workflows  ‐‐ 
between a buyer, a seller, and a shipper, for instance.  

For  example,  WSFL  allows  a  workflow  manager  to  call  from  a  composite  Web  service  each 
individual  Web  service  with  its  particular  role  in  a  business  process;  such  processes  could 
include managing financial reports, supporting forecasts and budgets in a five‐year IT plan, or 
making a hotel reservation. For instance, in making a hotel reservation, workflow components 
could include:  

• An  enterprise's  private  Web  services  collaborating  to  present  a  single  Web  service 
interface to the public. 
• Different  enterprises  providing  Web  services  in  a  collaborative  effort  to  perform 
business‐to‐business transactions. 

You  need  a  tool,  such  as  IBM  MQSeries  Workflow  (now  called  WebSphere  Process  Manager; 
see the sidebar), to define business processes as a series of activities, and to vary the sequence 
of these activities as the requirements for business processes change.  

271 
 
 
 

Back to top 

Suggested Web services stack 

The original Web services stack needs to be updated to incorporate IBM's new standards. This 
is achieved by the addition of several new layers: a service user interface/presentation layer, a 
service agreement layer, and a service security layer.Figure 3 illustrates the suggested stack. 

 
Figure  3.  Suggested  Web  services  stack 

Let's start with the topmost layer: the service user interface/presentation layer. The standard 
associated  with  this  layer  is  called  Web  Services  Experience  Language  (WSXL),  and  is  used  to 
describe  how  user  experiences  should  be  delivered  to  end  users  (for  example,  through  a 
browser,  or  a  portal,  or  by  embedding  into  a  third  party  interactive  Web  application).  It  is 
independent of presentation markup.  

WSXL  logically  sits  atop  the  WSFL,  as  user  experiences  depend  on  how  Web  services  are  to 
interact in workflows. The WSFL uses WSDL for the description of service interfaces and their 
protocol  bindings.  The  service  description  layer  for  WSDL  consists  of  two  components:  the 
service  implementation  layer  and  the  service  interface  layer.  The  definition  for  the 
implementation  layer  describes  how  a  service  provider  implements  a  service  interface.  You 
must create a service interface before you can implement WSDL.  

WSDL, in turn, relies on the WS‐Security specification, which, as the specification itself states, is 
used  to  describe  "how  to  attach  signature  and  encryption  headers  to  SOAP  messages."  (See 
Resources  for  the  full  specification.)  Included  in  the  security  specifications  are  other  types  of 
272 
 
 
message  attachments,  such  as  X.509  and  Kerberos  tickets.  IBM's  WSCA  1.0  specifies  how  the 
WSDL description of the service interface definition and the service implementation definition 
can  be  derived  from  the  UDDI  entries.  This  means  that  UDDI  is  used  as  a  service  registry  for 
WSDL‐based services.  

When not using UDDI, you may want to use the alternative WS‐Inspection as a parallel to the 
service  discovery  layer.  Both  standards  provide  "directory  assistance"  via  third‐party  sources. 
While WS‐Inspection primarily supports focused discovery (active search) patterns, along with 
some  unfocused  (open‐ended  browsing)  ones,  UDDI  (static)  is  limited  to  focused  discovery 
patterns. Additionally, WS‐Inspection has two other characteristics that UDDI does not possess: 
direct communication (via voice) and simple aggregate token (via business card), both of which 
are disseminated by the originator.  

As you can see in Figure 3, the service agreement layer has been inserted between the service 
flow  and  service  discovery  layers.  This  new  layer,  TPA  (short  for  Trading  Partner  Agreement), 
describes  an  agreement  between  two  partners  (for  example,  business  IBM  Software  Group 
Architecture Overview partners) on how they should interact regarding a service, as specified in 
the  service  flow  layer.  In  a  procurement/purchase  order  system,  the  seller  (the  service 
provider), for instance, must have Web services to receive request for quote (RFQ) messages, 
purchase  order  (PO)  messages,  invitation‐for‐bid  (IFB)  solicitation  query  messages,  and 
payment  messages.  The  buyer  (the  service  client)  must  have  Web  services  to  receive  RFQ 
quotes,  invoice  messages,  bid  award  notification  messages,  and  account  summary  messages. 
Between  the  provider  and  the  client  are  many  steps  involved  in  the  workflow  of  exchanging 
messages.  

Web Services Stacks 

To ensure interoperability when performing the publish, find and bind operations expressed in 
the Service Oriented Architecture (SOA) diagram; conceptual and technical standards must be 
defined  for  each  role  and  type  of  interaction.  This  section  will  explore  each  of  roles  and 
interactions in order identify each relevant stack of technologies. 

There  are  over  arching  concerns  involving  security,  management  and  quality  of  services  that 
must be addressed at each layer in the conceptual and technical stacks. The various solutions at 
each layer may or may not be independent of one other. More of these overarching concerns 
will emerge as the web services paradigm is adopted and evolved. What is most important is 
building a framework through which all such concerns may be applied to each of the layers in 
the stack so that as new concerns emerge they may be dealt with flexibly and consistently. 

At the end of this section we assemble the independent stacks into a single stack where each 
additional  layer  builds  upon  the  capabilities  provided  by  those  below  it.  The  vertical  towers 
represent the variety of over arching concerns that must be addressed at every level of each of 
the stacks. 

273 
 
 
An  important  point  is  that,  towards  the  bottom  layers  of  the  stack,  the  technologies  and 
concepts are relatively more mature and achieve a higher level of standardization than many of 
the  upper  layers.  The  maturation  and  adoption  of  Web  services  will  drive  the  continued 
development  and  standardization  of  the  higher  levels  of  the  stack  and  the  overarching 
concerns. 

3.3.1 Wire "Stack" 

The  wire  stack  encapsulates  the  concepts  and  technologies  dealing  with  the  actual  physical 
exchange of information between any of the roles in the SOA diagram. This includes the variety 
network transport, message packaging and message extensions that may be utilized to facilitate 
data exchange. 

3.3.1.1 Transport 

The  foundation  of  the  web  services  stack  is  the  network.  Web  services  must  be  network 
accessible to be invoked by a service requestor. Web services that are publicly available on the 

274 
 
 
Internet  use  commonly  deployed  network  protocols.  Because  of  its  ubiquity,  HTTP  is  the  de 
facto  standard  network  protocol  for  Internet‐available  web  services.  Other  Internet  protocols 
may be supported including SMTP and FTP. Intranet domains may use proprietary or platform 
and  vendor  specific  protocols  such  as  MQSeries,  CORBA,  etc..  The  specific  choice  of  network 
protocol used in any given scenario depends entirely upon application requirements, including 
concerns such as security, availability, performance, and reliability. This allows web services to 
capitalize  on  existing  higher  function  networking  infrastructures  and  message  oriented 
middleware, such as MQSeries. 

Within  an  enterprise  with  multiple  types  of  network  infrastructures,  HTTP  can  be  used  as  a 
common,  interoperable  bridge  to  connect  disparate  systems.  One  of  the  benefits  of  web 
services  is  that  it  provides  a  unified  programming  model  for  the  development  and  usage  of 
private Intranet as well as public Internet services. As a result, the choice of network technology 
can be made entirely transparent to the developer and consumer of the service. 

3.3.1.2 Packaging 

Moving up the Wire stack, the next layer, Packaging, represents the technologies that may be 
used to package information being exchanged. XML has been broadly adopted as the basis for 
Web service message packaging protocols. 

SOAP is a simple and lightweight XML‐based mechanism for creating structured data packages 
that  can  exchanged  between  network  applications.  SOAP  consists  of  four  fundamental 
components: an envelope that defines a framework for describing message structure, a set of 
encoding  rules  for  expressing  instances  of  application‐defined  data  types,  a  convention  for 
representing  remote  procedure  calls  (RPC)  and  responses,  and  a  set  of  rules  for  using  SOAP 
with HTTP. SOAP can be used in combination with a variety of network protocols; such as HTTP, 
SMTP, FTP, RMI/IIOP, or a proprietary messaging protocol. 

SOAP is currently the de facto standard for XML messaging for a number of reasons. First, SOAP 
is  relatively  simple,  defining  a  thin  layer  that  builds  on  top  of  existing  network  technologies 
such as HTTP that are already broadly implemented. Second, SOAP is flexible and extensible in 
that rather than trying to solve all of the various issues developers may face when constructing 
Web  services,  it  provides  an  extensible,  composable  framework  that  allows  solutions  to  be 
incrementally  applied  as  needed.  Thirdly,  SOAP  is  based  on  XML.  Finally,  SOAP  enjoys  broad 
industry and developer community support. 

3.3.1.3 Extensions 

Building  on  the  transport  and  packaging  layers,  the  final  layer  in  the  Wire  stack  provides  a 
framework  that  allows  additional  information  to  be  attached  to  Web  service  messages 
representing a variety of additional concerns; such as context, routing, policy, etc. As a key part 
of  its  envelope  message  structure,  SOAP  defines  a  mechanism  to  incorporate  orthogonal 
extensions (also known as features) to the message in the form of headers and encoding rules. 
It  is  expected  that  as  Web  services  are  adopted  and  evolved,  a  broad  collection  of  such 
extensions will emerge and be standardized. 
275 
 
 
3.3.2 XM
ML Messagin
ng with SOAP

Here is aan example  of how SOA AP, HTTP, annd the intern


net can be uused to implement the  Wire 
stack.  Th ws  how  XML  messagingg  (SOAP)  and  network  protocols 
he  following  figure  show p caan  be 
used as tthe basis of tthe web servvices architeecture. 

Editorial note    

CBF: misssing graphic... 

The  basic  requireme ents  for  a  neetwork  node  to  play  th


he  role  of  reequestor  or  provider  in  XML 
Messaginng based disstributed computing aree the abilityy to build an nd/or parse  a SOAP messsage 
and the aability to com
mmunicate o over a netwoork (receive and/or send d messages)). 

276 
 
 
Typically,  a  SOAP  Server  running  in  a  web  application  server  performs  these  functions. 
Alternatively,  a  programming  language‐specific  runtime  library  can  be  used  that  encapsulates 
these functions within an API. Application integration with SOAP can be achieved by using four 
basic steps: 

• In the Figure 1 above at (1), a service requestor’s application creates a SOAP message. 
This SOAP  message is the request that invokes the web service operation provided by 
the service provider. The XML document in the body of the message can be a SOAP RPC 
request  or  a  document‐centric  message  as  indicated  in  the  service  description.  The 
service  requestor  presents  this  message  together  with  the  network  address  of  the 
service provider to the SOAP infrastructure (e.g. a SOAP client runtime). The SOAP client 
runtime  interacts  with  an  underlying  network  protocol  (e.g.  HTTP)  to  send  the  SOAP 
message out over the network. 
• The network infrastructure delivers the message to the service provider’s SOAP runtime 
(e.g.  a  SOAP  server)  (2).  The  SOAP  server  routes  the  request  message  to  the  service 
provider's  web  service.  The  SOAP  runtime  is  responsible  for  converting  the  XML 
Message into programming language specific objects if required by the application. This 
conversion is governed by the encoding schemes found within the message. 
• The  web  service  is  responsible  for  processing  the  request  message  and  formulating  a 
response.  The  response  is  also  a  SOAP  message.  The  response  SOAP  message  is 
presented to the SOAP runtime with the service requestor as the destination (3). In the 
case  of  synchronous  request/response  over  HTTP,  the  underlying  request/response 
nature of the networking protocol is used to implement the request/response nature of 
the  messaging.  The  SOAP  runtime  sends  the  SOAP  message  response  to  the  service 
requestor over the network. 
• The  response  message  is  received  by  the  networking  infrastructure  on  the  service 
requestor’s  node.  The  message  is  routed  through  the  SOAP  infrastructure;  potentially 
converting  the  XML  message  into  objects  in  a  target  programming  language  (4).  The 
response message is then presented to the application. 

This example uses the request/response transmission primitive that is quite common in most 
distributed computing environments. The request/response exchange may be synchronous or 
asynchronous.  Other  transmission  primitives  such  as  one‐way  messaging  (no  response), 
notification (push style response), publish/subscribe are possible using SOAP. 

3.3.2.1 Interactions 

• One way: Message sent from requestor to provider. Provider may or may not return a 
response. If the provider returns a response, the requester may have already stopped 
‘listening’ for it or closed the communications channel. Response will be ‘thrown away’ 
and not processed by the requester 
• Conversational: Requester and Provider exchange multiple messages. Can be defined by 
choreography language. 
• Many‐to‐Many:  Requester  sends  message  to  many  providers.  Or,  service  provider 
responds to many requestors. Can be defined by choreography language. 

277 
 
 
3.3.3 Desscription "Sttack" 
Editorial note    

The  servvice  descripttion  layer  is  actually  a  stack 


s of  desscription  documents  deefined  using  XML 
Schema. 

It  is  thrrough  the  service  description  th hat  the  service  provider  commu unicates  all  the 
specifications for invvoking the W Web service tto the servicce requestorr. The service description is a 
key contributor to m making the W Web servicees architectu ure loosely ccoupled and d to reducingg the 
amount  of required  shared understanding,  custom pro ogramming aand integrattion between the 
service pprovider and the service requestor. FFor examplee, neither the requestor nor the pro ovider 
must be aware of the other's underlying platform, programming lan nguage, or d distributed o object 
model  (if 
( any).  Th he  service  description  combined  with  the  underlyingg  XML  Messsage 
infrastructure  defineed  in  the  Wire 
W stack  sufficiently  encapsulates
e s  this  detaill  away  from
m  the 
service reequestor's aapplication and the service provider’’s Web service. 

278 
 
 
We  desccribe  the  constituent  parts  of  th he  service  description 
d used  in  thhe  Web  serrvices 
architectture  in  two  groups,  tho
ose  used  to  fully  describ
be  one  Web
b  service  an
nd  those  useed  to 
describe interactionss or relationsships between sets of W Web services. 

Discovery
ry Agencies ""Stack" 

While  thhe  bottom  three  layeers  of  the  stack  identtify  technologies  for  compliance  and 
interoperability, the service publication and service disccovery can b
be implemen nted with a rrange 
of solutio
ons. 

on that makkes a WSDL  document aavailable to  a requestorr, at any stagge of the seervice 


Any actio
requesto
or’s lifecycle,, qualifies ass service pub
blication. 

Since  a  web  servicee  cannot  bee  discovered  if  it  has  not  been  published, 
p s
service  discoovery 
depends  upon  service  publicatiion.  The  varriety  of  disccovery  mechhanisms  parrallels  the  set 
s of 
publication mechanisms. Any meechanism that allows the service req questor to ggain access to the 
service  description 
d and  make  it 
i available  to  the  application  at  runtime  quaalifies  as  seervice 
279 
 
 
discovery. The simplest, most static example of discovery is static discovery wherein the service 
requestor  retrieves  a  WSDL  document  from  a  local  file.  This  is  usually  the  WSDL  document 
obtained through a direct publish or the results of a previous find operation. Alternatively, the 
service may be discovered at design time or run time using a local WSDL registry, or a public or 
private registry such as UDDI. The variety of service discovery mechanisms is discussed in more 
detail in the section titled Service Discovery. 

3.1 OVERVIEW 

Web services are a concept rather than a packaged solution to a well‐defined set of problems. 
Web services are based on XML and form a design center around XML, which in itself comprises 
a  number  of  standards.  It  would  go  beyond  the  scope  of  a  paper  like  this  to  list  all  of  the 
relevant  technologies  and  standards  components  that  might  be  included  in  an  overall  Web 
services  architecture.  (Much  more  information  is  available  on  the  Internet,  and  the  author 
strongly recommends keeping up‐to‐date with the rapidly evolving technologies related to Web 
services.)  Over  the  past  two  years,  a  number  of  companies  have  been  involved  in  the 
development  of  the  Web  services  architecture,  most  notably  IBM  and  Microsoft,  who  have 
been playing a vital role in bringing the first three components of the Web services model to 
the point of standardization. These three key Webservice technologies are: 

• a standardized way to describe Web services (Web Services Description Language, or WSDL). 

•  a  standardized  way  to  publish  and  discover  Web  services  (Universal  Description,  Discovery, 
and Integration, or UDDI). 

• a standardized way to invoke Web services (Simple Object Access Protocol, or SOAP). 

Service‐oriented architecture 

SOA = Service‐Oriented Architecture  

SOA  is  a  software  architecture  where  all  software‐implemented  tasks  and  processes  are 
designed as services to be consumed over a network. 

Keywords:  

1) architecture 

2) service 

SOA approach: 

The focus of design is the service interface. A service: 
280 
 
 
1) has a well‐defined interface 

2) can be potentially invoked over a network  

3) can be reused in multiple business contexts 

An application: 

1) is integrated at the interface and not implementation level 

2)  is  built  to  work  with  any  implementation  of  a  contract,  resulting    in  a  loosely  coupled  and 
more flexible system 

SOA Components 

1) roles 

a) service provider 

b) service requestor 

c) service registry 

2) operations 

a) publish 

b) bind 

c) find 

 
SOA Roles: Service Provider 
281 
 
 
What a service provider does? 

1) creates a service description 

2) deploys the service in a runtime environment to make it accessible to other entities 
over the network 

3) publishes the service description to one or more services registries 

4) receives messages invoking the service from service requestors 

SOA Roles: Service Requestor 

What a service requestor does? 

1) finds a service description published in a service registry 

2) applies the service description to bind and invoke the web service hosted by a service 
provider 

A service requestor can be any consumer of a web service. 

Any entity that hosts a network‐available web service is a service provider. 

SOA Roles: Service Registry 

What a service registry does? 

1) Accepts request from service providers to publish and advertise web service descriptions 

2) allows service requestors to search the collection of service descriptions contained within the 
service registry 

The  role  of  service  registry  is  to  enable  match‐making  between  service  providers  and  service 
requestors. 

Once the match has been found, the interactions are carried out directly between the service 
requestor and the service provider. 

SOA Operations: Publish 

The publish operation is an act of service registration or service advertisement. When a service 
provider publishes its web service in a service registry, it is advertising the service to the whole 
community of potential service requestors.  

The details of the publish operation depends on how the service registry is implemented. 

282 
 
 

 
SOA Operations: Find 

The find operation is an act of looking for a service satisfying certain conditions: 

1) service requestor states a search criteria, such as: the type of the service, its quality, etc. 

2)  service  registry  matches  the  search  criteria  against  the  published  web  service  descriptions 
The result is a list of service descriptions that match the search criteria. 

Details of the operation depend on the implementation of the service registry. 

 
SOA Operations: Bind 

The bind operation creates the client‐server relationship between service requestor and service 
provider.  

The operation can be: 

283 
 
 
1) dynamic ‐ creating a client‐side proxy on‐the‐fly based on the service description to invoke 
the web service 

2) static ‐ the developer hard‐codes the way the client invokes the web service 

 
 

SOA Properties 1 

SOA is a form of distributed systems architecture. 

It is characterized by: 

1)  Logical  view  ‐  a  service  is  an  abstraction  is  what  actual  programs,  databases,  businesses 
processes etc. are able to do. 

2)  Message  exchange  –  a  service  is  defined  in  terms  of  the  messages  exchanged  between 
provider and requestor agents and not in terms of the properties of the agents themselves 

3) abstraction – SOA hides the implementation details of the underlying languages, process and 
database structures, etc. 

4) meta‐data – a service is described by machine‐processable meta‐data   

5) small number of operations – a service tends to rely on a small number of operations with 
relatively large and complex messages 

6) network orientation ‐ services are oriented to their use over a network 

7)  platform‐neutral  ‐  messages  are  sent  in  a  standardized  format  delivered  through  the 
interfaces. XML is typically used. 

SOA Benefits 1 

SOA enables the agents participating in the message exchange to be loosely coupled, which in 
turn allows for more flexibility: 

284 
 
 
1) a client is only coupled to a service, not to a server ‐ the integration of the server takes place 
outside the scope of the client application  

2)  functional  components  and  their  interfaces  are  separated  ‐  new  interfaces  can  be  easily 
added 

3)  old  and  new  functionality  can  be  encapsulated  as  software  components  that  provide  and 
receive services 

4) the control of business processes can be isolated: 

a) business‐rule engine can control the workflow of a business process 

b) depending on the state, the engine invokes different services 

5) services can be incorporated dynamically during runtime 

6)  service  bindings  are  specified  using  configuration  files  and  can  be  easily  adapted  to  satisfy 
new needs 

Service Description in SOA 

The key to SOA is service description: 

1) it is published by the service provider in the service registry 

2) it is returned to the service requestor as a result of the search operatio 

3) it specifies to the service requestor: 

a) how to bind and invoke the web service 

b) what information is returned as a result of the invocation 

This  section  is  a  short  introduction  to  a  service‐oriented  architecture,  its  key  concepts,  and 
requirements.  You  will  find  a  more  thorough  description  of  service‐oriented  architectures  in 
Chapter10,  “Web  services  architectures”  on  page181.  (Be  aware  that,  because  the  presented 
architecture  makes  no  statements  about  the  infrastructure  or  protocols  it  uses,  the 
implementation of the service‐oriented architecture is not limited to Web technologies.) 

A service‐oriented architecture consists of three basic components:  

Service provider 

Service broker 

285 
 
 
Service requestor 

However, each component can also act as one of the two other components. For instance, if a 
service  provider  needs  some  more  information  that  it  can  only  acquire  from  some  other 
service, it acts as a service requestor while still serving the original request. Figure1‐1 shows the 
operations each component can perform. 

 
 

 The  service  provider  creates  a  Web  service  and  possibly  publishes  its  interface  and  access 
information to the service broker. Each provider must decide which services to expose, how to 
make trade‐offs between security and easy availability, and how to price the services (or, if they 
are free, how to exploit them for other value). The provider also has to decide what category 
the  service  should  be  listed  in  for  a  given  broker  service  and  what  sort  of  trading  partner 
agreements are required to use the service.  

 The service broker (also known as service registry) is responsible for making the Web service 
interface and implementation access information available to any potential service requestor. 
The implementers of a broker have to decide about the scope of the broker. Public brokers are 
available all over the Internet, while private brokers are only accessible to a limited audience, 
for  example,  users  of  a  company‐wide  intranet.  Furthermore,  the  width  and  breadth  of  the 
offered  information  has  to  be  decided.  Some  brokers  will  specialize  in  breadth  of  listings. 
Others will offer high levels of trust in the listed services. Some will cover a broad landscape of 
services, and others will focus within a given industry. Brokers will also arise that simply catalog 
286 
 
 
other brokers. Depending on the business model, a broker might attempt to maximize the look‐
up requests, number of listings, or accuracy of the listings.  

 The service requestor locates entries in the broker registry using various find  operations and 
then binds to the service provider in order to invoke one of its Web services.  

One important issue for users of services is the degree to which services are statically chosen by 
designers compared to those dynamically chosen at runtime. Even if most initial usage is largely 
static, any dynamic choice opens up the issues of how to choose the best service provider and 
how to assess quality of service. Another issue is how the user of services can assess the risk of 
exposure to failures of service suppliers. 

Characteristics 

The  presented  service‐oriented  architecture  employs  a  loose  coupling  between  the 


participants. Such a loose coupling provides greater flexibility:  

 In this architecture, a client is not coupled to a server, but to a service. Thus, the integration of 
the server to use takes place outside of the scope of the client application programs.  

 Old and new functional blocks are encapsulated into components that work as services.  

 Functional  components  and  their  interfaces  are  separated.  Therefore,  new  interfaces  can  be 
plugged in more easily.  

 Within complex applications, the control of business processes can be isolated. A business rule 
engine can be incorporated to control the workflow of a defined business process. Depending 
on the state of the workflow, the engine calls the respective services.  

 Services can be incorporated dynamically during runtime.  

Bindings are specified using configuration files and can thus easily be adapted to new needs. 

Requirements 

For  an  efficient  use  of  a  service‐oriented  architecture,  a  number  of  requirements  have  to  be 
fulfilled:  

 Interoperability  between  different  systems  and  programming  languages  The  most  important 
basis for a simple integration between applications on different platforms is a communication 
protocol that is available for most systems and programming languages. 

287 
 
 
 Clear and unambiguous description language To use a service offered by a provider, it is not 
only  necessary  to  be  able  to  access  the  provider  system,  but  also  the  syntax  of  the  service 
interface must be clearly defined in a platform‐independent fashion.  

 Retrieval of the service  

To allow a convenient integration at design time or even runtime of the system, we require a 
mechanism that  provides  search  facilities  to  retrieve  suitable  available services.  Such  services 
should be classified into computer‐accessible, hierarchical categories, or taxonomies, based on 
what the services in each category do and how they can be invoked.  

 Security  

Protection  of  the  services,  including  the  information  passed  to  and  received  from  the  service 
against  unauthorized  and  malicious  access,  must  be  supported  by  the  platform  to  win  the 
confidence of the requestor (chain)—at the end the business customers. The type and extent of 
security depends on the type and placement of the participants—service requestors and service 
providers—and the services themselves. Service usage monitoring and security incident action 
plans  have  to  be  in  place  to  detect  unauthorized  access  (attempts)  and  trigger  counter 
measures.  Security  is  required  to  empower  and  retain  authenticated  and  authorized 
requestors/customers while fencing off everything and everyone. 

Web services 

Web services are a relatively new technology that implements a service‐oriented architecture. 
During  the  development  of  this  technology,  a  major  focus  was  put  on  making  functional 
building  blocks  accessible  over  standard  Internet  protocols  that  are  independent  from 
platforms and programming languages.  

If we had to describe Web services using just one sentence, we would say:  

Web  services  are  self‐contained,  modular  applications  that  can  be  described,  published, 
located, and invoked over a network.  

Web  services  perform  encapsulated  business  functions,  ranging  from  simple  request‐reply  to 
full  business  process  interactions.  These  services  can  be  new  applications  or  just  wrapped 
around  existing  legacy  systems  to  make  them  network‐enabled.  Services  can  rely  on  other 
services to achieve their goals. 

Figure1‐2  shows  the  relationship  between  the  core  elements  of  Web  services  in  a  service‐
oriented architecture (SOA). 

288 
 
 

 
The following core technologies are used for Web services. These technologies are covered in 
detail in the subsequent chapters.  

XML  (Extensible  Markup  Language)  is  the  markup  language  that  underlies  most  of  the 
specifications  used  for  Web  services.  XML  is  a  generic  language  that  can  be  used  to  describe 
any kind of content in a structured way, separated from its presentation to a specific device.  

SOAP (Simple Object Access Protocol) is a network, transport, and programming language and 
platform‐neutral protocol that allows a client to call a remote service. The message format is 
XML.  WSDL  (Web  Services  Description  Language)  is  an  XML‐based  interface  and 
implementation description language. The service provider uses a WSDL document in order to 
specify  the  operations  a  Web  service  provides  and  the  parameters  and  data  types  of  these 
operations. A WSDL document also contains the service access information.  

WSIL  (Web  Services  Inspection  Language,  also  WS‐Inspection)  is  an  XML‐based  specification 
about how to locate Web services without the necessity of using UDDI. However, WSIL can be 
also used together with UDDI, that is, it is orthogonal to UDDI and does not replace it.  

Most  business  partners  today  do  not  find  one  another  from  UDDI  registries;  rather  they  are 
based  on  existing  relationships.  That  is  where  the  Web  Services  Inspection  Language  fits  in. 
WSIL  decentralizes  the  centralized  model  of  service  publication  within  a  UDDI  registry  and 
distributes  the  pieces  such  that  each  service  provider  itself  can  advertise  its  Web  Services 
offerings. WSIL thus facilitates the behavior that most businesses desiring to use Web Services 

289 
 
 
(today) are most comfortable with (today). Yet, WSIL is less widely used today as Web Service 
Registries take their place.  

UDDI (Universal Description, Discovery, and Integration) is both a client‐side API and a SOAP‐
based  server  implementation  that  can  be  used  to  store  and  retrieve  information  on  service 
providers and Web services. 

Properties of Web services All Web services share the following properties:  

Web  services  are  self‐contained.  On  the  client  side,  no  additional  software  is  required.  A 
programming language with XML and HTTP client support is enough to get you started. On the 
server side, merely an HTTP server and a SOAP server are required. It is possible to enable an 
existing application for Web services without writing a single line of code.  

Web services are self‐describing. 

The  definition  of  the  message  format  travels  with  the  message;  no  external  metadata 
repositories or code generation tools are required.  

 Web  services  can  be  published,  located,  and  invoked  across  the  Web.This  technology  uses 
established lightweight Internet standards such as HTTP. It leverages the existing infrastructure. 
Some additional standards thatare required to do so include SOAP, WSDL, and UDDI. 

Web services are modular. 

Simple  Web  services  can  be  aggregated  to  more  complex  ones,  either  using  workflow 
techniques  or  by  calling  lower‐layer  Web  services  from  a  Web  service  implementation.  Web 
services  can  be  chained  together  to  perform  higher‐level  business  functions.  This  shortens 
development time and enables best‐of‐breed implementations.  

 Web  services  are  language‐independent  and  interoperable.The  client  and  server  can  be 
implemented in different environments. Existing code does not have to be changed in order to 
be Web service enabled. Basically, any language can be used to implement Web service clients 
and servers. 

Web services are inherently open and standard‐based. 

XML  and  HTTP  are  the  major  technical  foundation  for  Web  services.  A  large  part  of  the  Web 
service technology has been built using open‐source projects. Therefore, vendor independence 
and interoperability are realistic goals.  

Web services are loosely coupled. 

290 
 
 
Traditionally,  application  design  has  depended  on  tight  interconnections  at  both  ends.  Web 
services require a simpler level of coordination that allows a more flexible reconfiguration for 
an integration of the services in question.  

Web services are dynamic. 

Dynamic e‐business can become reality using Web services, because with UDDI and WSDL, the 
Web  service  description  and  discovery  can  be  automated.  In  addition,  Web  services  can  be 
implemented and deployed without disturbing clients that use them.  

Web services provide programmatic access. The approach provides no graphical user interface; 
it operates at the code level. Service consumers have to know the interfaces to Web services 
but do not have to know the implementation details of services.  

 Web  services  provide  the  ability  to  wrap  existing  applications.  Already  existing  stand‐alone 
applications can easily be integrated into the service‐oriented architecture by implementing a 
Web service as an interface.  

 Web services build on proven, mature technology. There are a lot of commonalities, as well as 
a few fundamental differences, with other distributed computing frameworks. For example, the 
transport protocol is text based and not binary. 

Web Services Architecture‐‐Components, interactions and development cycle 

Web Services Technologies 
 

An architecture built around a client, a provider, and a registry. 

Web services depends on several enabling technologies including XML, SOAP, UDDI, and WSDL. 
In  the  following  sections  we  examine  UDDI  and  WSDL,  key  pieces  in  the  Web  services 
framework. 

The Web Services Architecture 

As Figure 5.2 illustrates, there are three major aspects to Web services: 

• A service provider provides an interface for software that can carry out a specified set of 
tasks. 
• A  service  requester  discovers  and  invokes  a  software  service  to  provide  a  business 
solution.  The  requester  will  commonly  invoke  a  remote  procedure  call  on  the  service 
provider, passing parameter data to the provider and receiving a result in reply. 

291 
 
 
• A  repository  or  broker  manages  and  publishes  the  service.  Service  providers  publish 
their services with the broker, and requests access those services by creating bindings to 
the service provider. 

The Web services triad includes a broker, a service provider, and a service requester. 
 

 
 

Key Technologies 
Web services builds on SOAP, UDDI, and WSDL. 

Web  services  relies  on  several  key  underlying  technologies,  in  particular,  UDDI,  WSDL,  and 
SOAP. 

UDDI is a protocol for describing Web services components that allows businesses to register 
with  an  Internet  directory  so  they  can  advertise  their  services  and  companies  can  find  each 
other and carry out transactions over the Web. 

292 
 
 
WSDL  is  the  proposed  standard  for  describing  a  Web  service.  WSDL  is  built  around  an  XML‐
based  service  Interface  Definition  Language  that  defines  both  the  service  interface  and  the 
implementation  details.  WSDL  details  may  be  obtained  from  UDDI  entries  that  describe  the 
SOAP messages needed to use a particular Web service. 

SOAP  is  a  protocol  for  communicating  with  a  UDDI  service  (see  Figure  5.3).  SOAP  simplifies 
UDDI access by allowing applications to invoke object methods or functions residing on remote 
servers.  The  advantage  of  SOAP  is  that  it  can  use  universal  HTTP  to  make  a  request  and  to 
receive  a  response.  SOAP  requests  and  responses  use  XML  not  only  to  target  the  remote 
method but to package any data that is required by the method. 

 Communication  involving  UDDI  uses  SOAP  to  package  UDDI  requests  and  replies  to  a  Web 
services repository. 
 

WS Components 

A web service includes three basic components: 

1) a mechanism to find and register interest in a service 
293 
 
 
2) a definition of the service’s input and output parameters 

3) a transport mechanism to access a service 

Web  services  also  include  other  technologies  that  can  be  used  to  provide  additional  features 
such as security, transaction processing and others. 

 
WS Process 

1) A service provider publishes a service to an external repository 

2) A client looks up for a service in the repository 

3) The repository returns information about the service: 

Call format 

Provider address 

4) The client binds to the underlying service 

5) The client calls and accesses the service 

294 
 
 
WS and Others 

Web services do not introduce new functionality. 

Similar functionality is provided by: 

1) Sun/RPC 

2) DCOM 

3) Enterprise Java Beans 

4) etc. 

The difference is how this functionality is provided. 

Web Service Application 

Consider the same application, but built as a web service. 

A client requests a file from the server. The server sends the file to the client.  

When received, the client saves the file on the local machine. 

The steps involved: 

1) setup the SOAP server 

2) develop the server 

3) develop the client 

4) start the web server 

5) deploy the server as a web service 

6) run the client application 

Web Service Example 1 

Running the application: 

1) the server is running on the auxiliary PC ‐ start the web server  

2) the client is running on the current PC‐run_client.bat 

295 
 
 

 
What happens if we enable a firewall on the server side? 

Let’s try again to run the client application: 

Web Service Example 2 

 
Comparison: Communication 

What is the observable difference between CORBA and WS applications?  

With the firewall enabled, the CORBA application was unable to run.One advantage of SOAP is 
its  explicit  definition  of  HTTP  binding  through  the  process  of  hiding  another  protocol  inside 
HTTP messages. 

This  allows  SOAP  messages  to  pass  through  a  firewall  unimpeded.Firewalls  will  usually  allow 
HTTP protocol through port 80, while they will restrict use of other protocols or ports. 

Comparison: 

296 
 
 
Functionality 

The same functionality in CORBA and WS. 

The difference is how WS provides this functionality: 

1) data is formatted for transfer using XML 

2) data is passed using standard communication protocols  

3) the exposed service is well defined in an XML vocabulary 

4)  services  are  found  in  standard  ways  with  XML  vocabularies  WS  provides  more  a  flexible 
design than CORBA. 

Comparison: Standards 

The main difference with past Distributed Computing Environments is adopted standards and 
implementations: 

1) a standard lookup service – UDDI 

2) a standard definition mechanism – WSDL 

3) a standard way for two parties to communicate – SOAP 

The foundation technology for all three (and more) is XML. 

Web Service Implementation 

The  standards  used  by  web  services  are  defined  with  little  concern  for  the  underlying 
implementation mechanism.  

Therefore:  a  web  service  written  in  C  and  running  on  Microsoft  IIS  can access a web 
service written in Java, running on BEA WebLogic Server. 

297 
 
 

 
Web Service Environments 

Several environments exist to build, deploy and access web services.  

Best known: 

1) Microsoft’s .Net Platform 

2) Sun’s Java 2 Platform 

We rely on Java Web Services. 

Traditional Communication 

Traditional system communication:  

1) systems must be tightly bound 

2) data must be transferred in such a way that two systems agree beforehand on the format 

3) various “network normal forms” were created to decide how bytes, integers, etc. were to be 
encoded for transfer 

XML‐Based Communication 

Before ‐ no common data‐definition mechanism. 

With XML: 

1) common, well‐defined data and representation 

2) well‐defined set of validity and well‐formedness rules Web service communication relies on 
XML syntax to write messages. 

WS ‐ Business Perspective 

Web services and business processes/goals: 
298 
 
 
1) a web service is an implementation of a business process or a step within such a process 

2) a web service is made available over a network to internal and/or external business partners 
to  achieve  specific  business  goals  Web  services  promote  integration of  applications  within  an 
organization and  between different business partners. 

Key feature: to allow for rapid construction of business applications by combining web services 
built internally with those of business partners. 

Web Service Usage 

Two main scenarios of web service usage: 

1) application integration 

2) B2B partner integration over the Internet 

WS Usage: B2B Integration 

 
Business‐to‐business (B2B) partner integration over the Internet. 

B2B integrates business systems of two or more companies to support  

cross‐enterprise business processes, e.g. supply chain management. 

WS Usage: Application Integration 

Legacy systems can be wrapped as web services and made available for integration with other 
systems. 

Applications exposed as web services are accessible by other applications running on different 
hardware platforms and written in different languages. 

Web Service Benefits 

1) platform integration ‐ the platform‐neutrality of WS allows combining  

business systems using different devices (PDAs, cell phones, desktops)  

with service providers of all sizes and shapes 
299 
 
 
2) software integration ‐ systems supporting new or modified business processes can be rapidly 
delivered by wrapping the existing functionality 

3)  standard  technology  ‐  open  standards  enable  developers  to  choose    among  different 
products, avoiding vendor‐dependence 

4)  small  businesses  integration  ‐  the  low  cost  of  WS  allows  small  businesses  to  deploy  and 
participate in WS applications 

5) easy integration ‐ interface‐based development using web service descriptions reduces the 
time to integrate applications 

SOA and WS 

Service‐Oriented Architecture: 

1) Provides an approach for building systems focused on a loosely coupled set of components 
(services) that can be dynamically composed 

2) promotes seamless software integration as a business benefit 

Web Services: 

1) one approach to building SOA 

2) provide a standard for a particular set of XML‐based technologies that can be used to build 
SOA systems 

WS‐Based Approach to SOA 

300 
 
 

 
Using SOA and WS 

SOA and WS are most appropriate for the applications that:  

1) can operate over the Internet, accepting that reliability and performance of communication 
cannot be guaranteed in this case 

2) do not require that all service requestors and providers are upgraded at the same time 

3)  consist  of  the  components  running  remotely  on  different  execution  platforms  and  vendor 
products 

4) were designed using legacy technology but need to be exposed for use over a network, using 
a web service wrapping 

4+1 view model‐logical view –process view –implementation view‐deployment view 

The  4  +  1  View  Model  describes  software  architecture  using  five  concurrent  views,  each  of 
which addresses a specific set of concerns: The logical view describes the design's object model, 
the process view describes the design's concurrency and synchronization aspects; the physical 
view  describes  the  mapping  of  the  software  onto  the  hardware  and  shows  the  system's 
distributed  aspects,  and  the  development  view  describes  the  software's  static  organization  in 
the  development  environment.  Software  designers  can  organize  the  description  of  their 
architectural  decisions  around  these  four  views  and  then  illustrate  them  with  a  few  selected 
301 
 
 
use cases, or scenarios, which constitute a fifth view. The architecture is partially evolved from 
these scenarios. The 4+1 View Model allows various stakeholders to find what they need in the 
software architecture. System engineers can approach it first from the physical view, then the 
process view; end users, customers, and data specialists can approach it from the logical view; 
and  project  managers  and  software‐configuration  staff  members  can  approach  it  from  the 
development view.  

 
 
•  The  logical  view,  which  is  the  object  model  of  the  design  (when  an  object‐oriented 
design method is used), 
 
• The process view, which captures the concurrency and synchronization aspects of the 
design, 
 
• The physical view, which describes the mapping(s) of the software onto the hardware 
and reflects its distributed aspect, 
 
• The development view, which describes the static organization of the software in its 
development environment. 
 

 
 

302 
 
 
• Use‐case  view:  Describes  functionality  of  the  system,  its  external  interfaces,  and  its 
principal users. This view is mandatory when using the 4+1 Views, because all elements 
of the architecture should be derived from requirements.  
• Logical  view:  Describes  how  the  system  is  structured  in  terms  of  units  of 
implementation.  The  elements  are  packages,  classes,  and  interfaces.  The  relationship 
between elements shows dependencies, interface realizations, part‐whole relationships, 
and  so  forth.  Note:  This  view  is  mandatory  when  using  the  4+1  Views  of  Software 
Architecture.  
• Implementation  view:  Describes  how  development  artifacts  are  organized  in  the  file 
system.  The  elements  are  files  and  directories  (any  configuration  items).  This  includes 
development  artifacts  and  deployment  artifacts.  This  view  is  optional  when  using  the 
4+1 Views.  
• Process view: Describes how the run‐time system is structured as a set of elements that 
have  run‐time  behavior  and  interactions.  Run‐time  structure  often  bears  little 
resemblance  to  the  code  structure.  It  consists  of  rapidly  changing  networks  of 
communication  objects.  The  elements  are  components  that  have  run‐time  presence 
(processes,  threads,  Enterprise  JavaBeans™  (EJB™),  servlets,  DLLs,  and  so  on),  data 
stores, and complex connectors, such as queues. Interaction between elements varies, 
based  on  technology.  This  view  is  useful  for  thinking  about  run‐time  system  quality 
attributes, such as performance and reliability. This view is optional when using the 4+1 
Views.  
• Deployment  view:  Describe  how  the  system  is  mapped  to  the  hardware.  This  view  is 
optional when using the 4+1 Views.  

In addition, you may wish to represent the following,  

• Data view: A specialization of the logical view. Use this view if persistence is a significant 
aspect  of  the  system,  and  the  translation  from  the  design  model  to  the  data  model  is 
not done automatically by the persistence mechanism.  

 
 
Underlying Architectural Framework 
 
This architecture follows the “4+1” framework [Kruchten 1995] that defines a set 
of “Views” of the architecture. 
 
Correspondence Between the Views 
 
The various views are not fully orthogonal or independent. Elements of one view are connected 
to elements 
in other views, following certain design rules and heuristics. 
 
From the logical to the process view 
 
We identify several important characteristics of the classes of the logical architecture: 
303 
 
 
• Autonomy: are the objects active, passive, protected?‐an active object takes the initiative of 
invoking  other  objects’  operations  or  its  own  operations,  and  has  full  control  over  the 
invocation of its own operations by other objects ‐a passive object never invokes spontaneously 
any operations and has no control over the invocation of its own operations by other objects ‐ a 
protected object never invokes spontaneously any operations but performs some arbitration on 
the invocation of its operations. 
•  Persistence:  are  the  objects  transient  ,  permanent?  Do  they  the  failure  of  a  process  or 
processor? 
• Subordination: are the existence or persistence of an object depending on another object? 
• Distribution: are the state or the operations of an object accessible from many nodes in the 
physical architecture, from several processes in the process architecture? 
In  the  logical  view  of  the  architecture  we  consider  each  object  as  active,  and  potentially 
“concurrent,”  i.e.,behaving  “in  parallel”  with  other  objects,  and  we  pay  no  more  attention  to 
the exact degree of concurrency we need to achieve this effect. Hence the logical architecture 
takes into account only the functional aspect of the requirements. 
However when we come to defining the process architecture, implementing each object with 
its  own  thread  of  control  (e.g.,  its  own  Unix  process  or  Ada  task)  is  not  quite  practical  in  the 
current state of technology, because of the huge overhead this imposes. Moreover, if objects 
are concurrent, there must be some form of arbitration for invoking their operations. 
 

From logical to development 
 
A  class  is  usually  implemented  as  a  module,  for  example  a  type  in  the  visible  part  of  an  Ada 
package.  Large  classes  are  decomposed  into  multiple  packages.  Collections  of  closely  related 
classes—class  categories—are  grouped  into  subsystems.  Additional  constraints  must  be 
considered for the definition of subsystems,such as team organization, expected magnitude of 
code (typically 5K to 20K SLOC per subsystem), degree of expected reuse and commonality, and 
strict  layering  principles  (visibility  issues),  release  policy  and  configuration  management. 
Therefore we usually end up with a view that does not have a one to one correspondence with 
the logical view. 
The  logical  and  development  views  are  very  close,  but  address  very  different  concerns.  We 
have found that the larger the project, the greater the distance between these views. Similarly 
for the process and physical views: the larger the project, the greater the distance between the 
views. For example, if we compare fig. 3b and fig. 6, there is no one to one mapping of the class 
categories  to  the  layers.  If  we  take  the  ‘External  interfaces—Gateway’  category,  its 
implementation is spread across several layers: communications protocols are in subsystems in 
or  below  layer  1,  general  gateway  mechanisms  are  in  subsystems  in  layer  2,  and  the  actual 
specific gateways in layer 5 subsystems. 
 
From process to physical 
Processes  and  process  groups  are  mapped  onto  the  available  physical  hardware,  in  various 
configurations  for  testing  or  deployment.  Birman  describes  some  very  elaborate  schemes  for 
this  mapping  in  the  Isis  project5.The  scenarios  relate  mostly  to  the  logical  view,  in  terms  of 
which classes are used, and to the process view when the interactions between objects involve 
more than one thread of control. 
304 
 
 
 

A scenario‐driven approach 
 
The most critical functionality of the system is captured in the form of scenarios (or use cases). 
By critical we mean: functions that are the most important, the raison d’être of the system, or 
that have the highest frequency of use, or that present some significant technical risk that must 
be mitigated. 
Start: 
•  A  small  number  of  the  scenarios  are  chosen  for  an  iteration  based  on  risk  and  criticality. 
Scenarios may be synthesized to abstract a number of user requirements. 
• A strawman architecture is put in place. The scenarios are then “scripted” in order to identify 
major  abstractions  (classes,  mechanisms,  processes,  subsystems)  as  indicated  by  Rubin  and 
Goldberg6 — decomposed in sequences of pairs (object, operation). 
•  The  architectural  elements  discovered  are  laid  out  on  the  4  blueprints:  logical,  process, 
development, and physical. 
• This architecture is then implemented, tested, measured, and this analysis may detect some 
flaws or potential enhancement. 
• Lessons learned are captured. 
Loop: 
The next iteration can then start by: 
• reassessing the risks, 
• extending the palette of scenarios to consider 
•  selecting  a  few  additional  scenarios  that  will  allow  risk  mitigation  or  greater  architecture 
coverage 
Then: 
• Try to script those scenarios in the preliminary architecture 
•  discover  additional  architectural  elements,  or  sometimes  significant  architectural  changes 
that need to occur to accommodate these scenarios 
• update the 4 main blueprints: logical, process, development, physical 
• revise the existing scenarios based on the changes 
• upgrade the implementation (the architectural prototype) to support the new extended set of 
scenario. 
• Test. Measure under load, in real target environment if possible. 
•  All  five  blueprints  are  then  reviewed  to  detect  potential  for  simplification,  reuse, 
commonality. 
• Design guidelines and rationale are updated. 
• Capture the lessons learned. 
 

 
 
 
 
 
 

305 
 
 
 
Unit III 

Web Services Building Block 
Transport protocols for web services 
Messaging with web services  
Protocols  
SOAP 
Describing web services  
WSDL  
Anatomy of WSDL 
Manipulating WSDL 
Web service policy 
Discovering web services  
UDDI 
Anatomy of UDDI 
Web service inspection 
Ad Hoc Discovery 
Securing web services  

Building a Web Service 

Web Service Development Tasks 

The following tasks are interdependent but not entirely sequential. For example, you can add a 
method reference while creating a web service or afterward.Webservice development is an 
iterative process. 

The tasks, in general order of development workflow, are: 

ƒ Creating a SOAP RPC web service 
ƒ Developing XML operations (if needed) 
ƒ Adding method references to a web service 
ƒ Resolving references to runtime objects 
ƒ Adding environment entries 
ƒ Generating runtime classes 
ƒ Assembling and deploying a web service as a J2EEapplication 
ƒ Creating a test client 
ƒ Testing a web service 
ƒ Working with UDDI registries 

306 
 
 
 

Web services 

Web services are a relatively new technology that implements a service‐oriented architecture. 
During  the  development  of  this  technology,  a  major  focus  was  put  on  making  functional 
building  blocks  accessible  over  standard  Internet  protocols  that  are  independent  from 
platforms and programming languages.  

If we had to describe Web services using just one sentence, we would say:  

Web  services  are  self‐contained,  modular  applications  that  can  be  described,  published, 
located, and invoked over a network.  

Web  services  perform  encapsulated  business  functions,  ranging  from  simple  request‐reply  to 
full  business  process  interactions.  These  services  can  be  new  applications  or  just  wrapped 
around  existing  legacy  systems  to  make  them  network‐enabled.  Services  can  rely  on  other 
services to achieve their goals. 

Figure1‐2  shows  the  relationship  between  the  core  elements  of  Web  services  in  a  service‐
oriented architecture (SOA). 

 
307 
 
 

 
The following core technologies (standards) are used for Web services.  

XML  (Extensible  Markup  Language)  is  the  markup  language  that  underlies  most  of  the 
specifications  used  for  Web  services.  XML  is  a  generic  language  that  can  be  used  to  describe 
any kind of content in a structured way, separated from its presentation to a specific device.  

SOAP (Simple Object Access Protocol) is a network, transport, and programming language and 
platform‐neutral  protocol  that  allow  a  client  to  call  a  remote  service.  The  message  format  is 
XML.   

SOAP is a transport‐independent messaging protocol. Each SOAP message is an XML document. 
SOAP  uses  one‐way  messages,  although  it’s  possible  to  combine  messages  into  request‐and‐
response sequences.  

The SOAP specification defines the format of the XML message but not its content and how it’s 
actually sent. SOAP does, however, specify how SOAP messages are routed over HTTP. 

Each SOAP document has a root <Envelope> element. The root element, the first element in an 
XML document, contains all the other elements in the document.  

Within  the  “envelope”  are  two  parts:  a  header  and  a  body.  The  header  contains  routing  or 
context data. It can be empty. The body contains the actual message. It too can be empty. 

308 
 
 

 
WSDL  (Web  Services  Description  Language)  is  an  XML‐based  interface  and  implementation 
description  language.  The  service  provider  uses  a  WSDL  document  in  order  to  specify  the 
operations a Web service provides and the parameters and data types of these operations. A 
WSDL document also contains the service access information.  

A web service is useless unless others can find out what it does and howto call it. Developers 
must know enough information about a web serviceso they can write a client program that calls 
it.  WSDL  is  an  XML‐based  language  used  to  define  web  services  and  describe  how  to  access 
them.  Specifically,  it  describes  the  data  and  message  contracts  a  web  service  offers.  By 
examining a web service’s WSDL document, developers know what methods are available and 
how to call them using the proper parameters. 

309 
 
 
WSIL  (Web  Services  Inspection  Language,  also  WS‐Inspection)  is  an  XML‐based  specification 
about how to locate Web services without the necessity of using UDDI. However, WSIL can be 
also  used  together  with  UDDI,  that  is,  it  is  orthogonal  to  UDDI  and  does  not  replace  it.  Most 
business partners today do not find one another from UDDI registries; rather they are based on 
existing  relationships.  That  is  where  the  Web  Services  Inspection  Language  fits  in.  WSIL 
decentralizes the centralized model of service publication within a UDDI registry and distributes 
the pieces such that each service provider itself can advertise its Web Services offerings. WSIL 
thus facilitates the behavior that most businesses desiring to use Web Services (today) are most 
comfortable  with  (today).  Yet,  WSIL  is  less  widely  used  today  as  Web  Service  Registries  take 
their place.  

 
UDDI (Universal Description, Discovery, and Integration) is both a client‐side API and a SOAP‐
based  server  implementation  that  can  be  used  to  store  and  retrieve  information  on  service 
providers and Web services. 

UDDI is an evolving standard for describing, publishing, and discovering the web services that a 
business provides. It’s a specification for a distributed registry of information on web services. 
Once a web service is developed and a WSDL document describing it is created, there needs to 
be a way to get the WSDL information into the hands of the users who want to use the web 
service it describes. When a web service is published in a UDDI registry, potential users have a 
way to look up and learn about the web service’s existence. 

The content of a UDDI registry is similar to a telephone directory. In the “white pages” section 
of the registry is information such as the name, address, and telephone number of the business 
that offers one or more web services. The “yellow pages” section identifies the business type 
and  categorizes  it  by  industry.  The  “green  pages”  section  provides  the  data  about  the  web 
services the business offers. 

310 
 
 

 
 

Properties of Web services 

All Web services share the following properties:  

Web services are self‐contained. 

On  the  client  side,  no  additional  software  is  required.  A  programming  language  with 
XML and HTTP client support is enough to get you started. On the server side, merely an 
HTTP  server  and  a  SOAP  server  are  required.  It  is  possible  to  enable  an  existing 
application for Web services without writing a single line of code.  

Web services are self‐describing. 

The  definition  of  the  message  format  travels  with  the  message;  no  external  metadata 
repositories or code generation tools are required.  

Web services can be published, located, and invoked across the Web. 

This  technology  uses  established  lightweight  Internet  standards  such  as  HTTP.  It 
leverages the existing infrastructure. Some additional standards that are required to do 
so include SOAP, WSDL, and UDDI. 

Web services are modular. 

Simple  Web  services  can  be  aggregated  to  more  complex  ones,  either  using  workflow 
techniques or by calling lower‐layer Web services from a Web service implementation. 
Web services can be chained together to perform higher‐level business functions. This 
shortens development time and enables best‐of‐breed implementations.  

Web services are language‐independent and interoperable. 

311 
 
 
The client and server can be implemented in different environments. Existing code does 
not have to be changed in order to be Web service enabled. Basically, any language can 
be used to implement Web service clients and servers. 

2  

Web services are inherently open and standard‐based. 

XML and HTTP are the major technical foundation for Web services. A large part of the 
Web  service  technology  has  been  built  using  open‐source  projects.  Therefore,  vendor 
independence and interoperability are realistic goals.  

Web services are loosely coupled. 

Traditionally,  application  design  has depended  on  tight  interconnections  at  both  ends. 
Web  services  require  a  simpler  level  of  coordination  that  allows  a  more  flexible 
reconfiguration for an integration of the services in question.  

Web services are dynamic. 

Dynamic  e‐business  can  become  reality  using  Web  services,  because  with  UDDI  and 
WSDL, the Web service description and discovery can be automated. In addition, Web 
services can be implemented and deployed without disturbing clients that use them.  

Web services provide programmatic access. 

The approach provides no graphical user interface; it operates at the code level. Service 
consumers have  to  know  the  interfaces  to  Web  services  but  do  not  have  to  know  the 
implementation details of services. 

Web services provide the ability to wrap existing applications. 

Already  existing  stand‐alone  applications  can  easily  be  integrated  into  the  service‐
oriented architecture by implementing a Web service as an interface.  

Web services build on proven, mature technology. 

There are a lot of commonalities, as well as a few fundamental differences, with other 
distributed computing frameworks. For example, the transport protocol is text based and not 
binary. 

Transport protocols for web services  

Web services stack 

312 
 
 
The transport layer is the foundation of the Web services stack. Web services must be invoked 
by a service client so they can be accessible to a network. Web services that are publicly 
available run over the Internet. Only the authorized users within an internal organization can 
view intranet‐available Web services, while unauthorized users in the outside world cannot. It is 
possible to create extranet‐based Web services to allow legitimate users access to them on 
more than one intranet. 

The Internet protocols that can be supported by this stack are HTTP and, to a lesser extent, 
SMTP (for electronic mail) and FTP (for file transfer). Intranet domains use middleware call 
infrastructures, such as IBM's MQSeries, and CORBA (the Common Object Request Broker 
Architecture). The latter relies on a protocol called the Internet Inter‐ORB Protocol (IIOP) for 
remote objects. 

HTTP has a special status in the W3C Web Services Architecture for a number of both practical 
and theoretical reasons. For one, early versions of SOAP (and XML‐RPC, which is still widely 
used in existing web services) were explicitly tied to HTTP. SOAP 1.1 implied a certain amount of 
protocol‐independence, and SOAP 1.2 makes this explicit, but HTTP is still the dominant means 
of communicating between web services agents. Also, HTTP is 

4.3.2 Other Protocols 

Many believe that HTTP is the "native" protocol of the Web because it was designed to work 
with the URIs that identify Web resources. While HTTP has become almost ubiquitous, and 
many of the issues surrounding its earlier incarnations have been resolved in subsequent 
versions of the standard and by "industrial strength" implementations, it is not the only 
protocol upon which Web services can be built. For example 

• TCP 
• UDP 
• BEEP 
• JMS Service Provider's protocol 
• proprietary messaging systems 
313 
 
 
 

SOAP Transport Protocol 

Client requests and web service responses are transmitted as Simple Object Access Protocol 
(SOAP) messages over HTTP to enable a completely interoperable exchange between clients 
and web services, all running on different platforms and at various locations on the Internet. 
HTTP is a familiar request‐and response standard for sending messages over the Internet, and 
SOAP is an XML‐based protocol that follows the HTTP request‐and‐response model. 

The SOAP portion of a transported message handles the following: 

• Defines an XML‐based envelope to describe what is in the message and how to process 
the message 
• Includes XML‐based encoding rules to express instances of application‐defined data 
types within the message 
• Defines an XML‐based convention for representing the request to the remote service 
and the resulting response 

Web Service Messaging 

A client sends a request message to a web service, and receives a response message. 

Messaging Protocols 

The most common transport used for Web services interoperability is HTTP, and the most 
common encodings used by Web services are XML‐based SOAP 1.1, SOAP 1.2, and Message 
Transmission Optimization Mechanism (MTOM). 

Web services are defined based on XML messaging, and the following three parameters 
describe a given web service's messaging interaction. 

1. Message exchange pattern 
2. Synchronous and asynchronous client API 
3. One‐way/two‐way behavior of the transport 
314 
 
 
Message Exchange Patterns 

The sequence of messages involved in the Web service operation invocation is referred to as 
the message exchange pattern 

When a client and a web service communicate they exchange messages. A request message 
is sent from the client to the web service. The web service responds with a response 
message. This is just like in ordinary HTTP, where a web browser sends an HTTP request to a 
web server, and the web server replies with an HTTP response.  

In the beginning the only web service message format available was SOAP. L