Xml

XML Presented by Prof. Venkat Krishnan

Prof Venkat Krishnan (SCJP, SCWCD, SCJD, MCSD, Rational Certified)

Visiting Faculty at: S.P.Jain Inst of Management Somaiya Institute of Management CMIT Corporate Trainings offered at: Air India ABN Amro Kale Consultants Supreme Technologies IDBI Associated with: Champlain College (UK) Southern New Hampshire (UK) Malboro College (US) Charles Strut University (Aus) Northwood University (US) Prof.Venkat Krishnan

Coming up… Basics about XML (1 to 65) DTD (66 to 96) Schema (97 to 180) W3C DOM & Data Binding (181 to 218) XSL and XSLT (219 to 293) Java & XML

XML stands for Extensible Markup Language XML is a set of rules for defining semantic tags that break a document into parts and identify the different parts of the document. It is a meta-markup language that defines a syntax in which other field-specific markup languages can be written. XML, however, is a meta-markup language. It’s a language in which you make up the tags you need as you go along. These tags must be organized according to certain general principles, but they’re quite flexible in their meaning. The tags you create can be documented in a Document Type Definition (DTD).

XML defines the meta syntax that field-specific markup languages such as MusicML, MathML, and CML must follow. It specifies the rules for the low-level syntax, saying how markup is distinguished from content, how attributes are attached to elements, and so forth without saying what these tags, elements, and attributes are or what they mean. A browser does not need to know in advance each and every tag that might be used by thousands of different markup languages. Instead, it discovers the tags used by any given document as it reads thedocument or its DTD.

XML is the Extensible M arkup L anguage Similar to HTML in format HTML specifies presentation XML specifies data structure Allows definition of your own tags and attributes (extensible) How XML and SGML Are Related SGML provides the specification for writing markup languages HTML would be an implementation of SGML XML is a subset of SGML XML and SGML do not define the meaning of the language elements This is the role of the Document Type Definition (DTD) or Extensible Style sheet Language (XSL) file SGML is very powerful With that power comes complexity, making the language difficult to use XML was designed with the goal of capturing all that was good in SGML, while keeping it as simple as possible

A Simple XML Example: an Address Book <?xml version="1.0"?> <addressBook> <entry> <name> <first>Venkat</first> <last>Krishnan</last> </name> <address> <street1>I-101 Pranay Nagar Borivali</street1> <street2/> <city>Mumbai</city> <zipcode>400092</zipcode> </address> </entry> </addressBook>

XML describes structure and semantics, not formatting The thing to understand about XML is that XML markup describes a document’s structure and meaning. It does not describe the formatting of the elements on the page. Formatting can be added to a document with a style sheet. The document itself only contains tags that say what is in the document, not what the document looks like. By contrast, HTML encompasses formatting, structural, and semantic markup. is a formatting tag that makes its content bold. Open Standard World Wide Web Consortium (W3C) Derived from the Standard Generalized Markup Language (SGML) Passed as W3C Standard February 1998 (although many aspects of XML are still being defined) Text Based International support via the Unicode character set

Extensible Markup Language ( XML ) is a buzzword you will see everywhere on the Internet, but it's also a rapidly maturing technology with powerful real-world applications, particularly for the management, display and organization of data. XML is a technology concerned with the description and structuring of data , so before we can really delve into the concepts behind XML, we need to understand how data is stored and accessed by computers. For our purposes, there are two kinds of data files that are understood by computers: text files and binary files . A binary file , at its simplest, is just a stream of bits (1's and 0's). It's up to the application that created a binary file to understand what all of the bits mean. That's why binary files can only be read and produced by certain computer programs, which have been specifically written to understand them. Like binary files, text files are also streams of bits. However, in a text file these bits are grouped together in standardized ways, so that they always form numbers. These numbers are then further mapped to characters. More on XML

A Brief History of Markup We can see that there are advantages to binary file formats (easy to understand by a computer, compact), as well as advantages to text files (universally interchangeable). Wouldn't it be ideal if there were a format that combined the universality of text files with the efficiency and rich information storage capabilities of binary files? An early attempt to combine a universally interchangeable data format with rich information storage capabilities was SGML ( Standard Generalized Markup Language ). This is a text-based language that can be used to mark up data–that is, add meta data–in a way which is self-describing . A very well-known language, based on the SGML work, is the HyperText Markup Language , or HTML . HTML uses many of SGML's concepts to provide a universal markup language for the display of information, and the linking of different pieces of information. Unfortunately, SGML is such a complicated language that it's not well suited for data interchange over the web. And, although HTML has been incredibly successful, it's also limited in its scope: it is only intended for displaying documents in a browser.

The tags it makes available do not provide any information about the content they encompass, only instructions on how to display that content. XML is a subset of SGML, with the same goals (mark up of any type of data), but with as much of the complexity eliminated as possible. XML was designed to be fully compatible with SGML, which means that any document which follows XML's syntax rules is by definition also following SGML's syntax rules, and can therefore be read by existing SGML tools. It doesn't go both ways though, so an SGML document is not necessarily an XML document.might create an XML file like this: <name> <first>Venkat</first> <last>Krishnan</last></name> Even from this simple example you can see why markup languages like SGML and XML are called "self-describing". Looking at the data, you can easily tell that this is information about a <name>, and you can see that there is data called <first> and more data called <last>. I could have given the tags any names I liked, however, if you're going to use XML, you might as well use it right, and give things meaningful names.Now open the file inside the IE Browser

How It Works Although our XML file has no information concerning display, IE formats it nicely for us, with our information in bold, and our markup displayed in different colors. Also, <name> is collapsible, like your file folders in Windows Explorer; try clicking on the - sign next to <name> in the browser window. For large XML documents, where you only need to concentrate on a smaller subset of the data, this can be quite handy. This is one reason why IE can be so helpful when authoring XML: it has a default stylesheet built in, which applies this default formatting to any XML document. XML styling is accomplished through another document dedicated to the task, called a stylesheet. In a stylesheet the designer specifies rules that determine the presentation of the data. The same stylesheet can then be used with multiple documents to create a similar appearance among them. There are a variety of languages that can be used to create stylesheets.

XML Parsers If we just follow the rules specified by XML, we can be sure that it will be easy to get at our information. This is because there are programs written, called parsers , which are able to read XML syntax and get the information out for us. We can use these parsers within our own programs, meaning our applications never have to even look at the XML directly; a large part of the workload will have been done for us.

Why "Extensible"? Since we have full control over the creation of our XML document, we can shape the data in any way we wish, so that it makes sense to our particular application. If we want to create data in a way that only one particular computer program will ever use, we can do so. And if we feel that we want to share our data with other programs, or even other companies across the Internet, XML gives us the flexibility to do that as well. We are free to structure the same data in different ways that suit the requirements of an application or category of applications. There is, of course, a fundamental difference between HTML and XML: HTML is designed for a specific application; to convey information to humans (usually visually, through a web browser) XML has no specific application; it is designed for whatever use you need it for

Hierarchies in HTML For example, when working with Dynamic HTML ( DHTML ) there is an object model available for working with HTML documents, called the Document Object Model or DOM . This allows us to write code in an HTML document, like the following JavaScript: alert(document.title); Here we are using the alert() function to pop up a message box telling us the title of an HTML document. That's done by accessing an object called document, which contains all of the information needed about the HTML document. The document object includes a property called title, which returns the title of the current HTML document. Hierarchies in XML XML also groups information in hierarchies. The items in our documents relate to each other in parent/child and sibling/sibling relationships. These "items" are called elements .

What Is the World Wide Web Consortium? One of the reasons that HTML and XML are so successful is that they're standards . That means that anyone can follow these standards, and the solutions they develop will be able to interoperate. So who creates these standards? The World Wide Web Consortium ( W3C ) was started in 1994, according to their web site ( http://www.w3.org/ ), "to lead the World Wide Web to its full potential by developing common protocols that promote its evolution and ensure its interoperability". Recognizing this need for standards, the W3C produces Recommendations that describe the basic building blocks of the Web. They call them recommendations, instead of standards, because it is up to others to follow the recommendations to provide the interoperability. Their most famous contribution to the Web is, of course, the HTML Recommendation; when a web browser producer claims that their product follows version 3.2 or 4.01 of the HTML Recommendation, they're talking about the Recommendation developed under the authority of the W3C.

Namespaces provide a means to distinguish one XML vocabulary from another, which allows us to create richer documents by combining multiple vocabularies into one document type. XPath describes a querying language for addressing parts of an XML document. This allows applications to ask for a specific piece of an XML document, instead of having to always deal with one large "chunk" of information. For example, XPath could be used to get "all the last names" from a document As we discussed earlier, in some cases we may want to display our XML documents. For simpler cases, we can use Cascading Style Sheets ( CSS ) to define the presentation of our documents. And, for more complex cases, we can use Extensible Stylesheet Language ( XSL ), that consists of XSLT , which can transform our documents from one type to another. XLink and XPointer are languages that are used to link XML documents to each other, in a similar manner to HTML hyperlinks. To provide a means for more traditional applications to interface with XML documents, there is a document object model–the DOM. An alternative way for programmers to interface with XML documents from their code is to use the Simple API for XML ( SAX ).

Why Are Developers Excited About XML? Design of field-specific markup languages: XML enables individual professions (e.g., music, chemistry, human resources) to develop their own field-specific markup languages. These languages make it possible for practitioners in the field to trade notes, data, and information without worrying about whether or not the person on the receiving end has the particular proprietary payware that was used to create the data. They can even send documents to people outside the profession with reasonable confidence that the people who receive them will at least be able to view the documents. Self-describing data: At a higher level, XML is self-describing. The tags are self explanatory Interchange of data among applications: Because XML is nonproprietary and easy to read and write, it’s an excellent formatfor the interchange of data among different applications. Structured and integrated data: XML is ideal for large and complex documents because the data is structured. It not only lets you specify a vocabulary that defines the elements in the document; it also lets you specify the relations between elements. For example, if you’re putting together a Web page of sales contacts, you can require that every contact have a phone number and an e-mail address. If you’re inputting data for a database, you can make sure that no fields are missing. You can even provide default values to be used when no data is entered.

The Myths: XML is a replacement for HTML HTML is a markup language XML is a markup language and a specification language XML will solve all your problems XML provides an infrastructure for a solution, but it is not the solution XML is only part of the application architecture; alone it does nothing XML is very simple: there's not much too it Learning the syntax of XML is easy, but it is not enough There is more to XML than "tags"

Comparing HTML to XML HTML Strengths and Weaknesses HTML Strengths Portable Easy to understand and use Widely used Free tools HTML Weaknesses Data is mixed with presentation Does not allow precise searching of content Inflexible - fixed number of tags Lacks data structure

Solving the Tags Dilemma Split Data from Presentation XML deals with data Style sheets deal with presentation No Predefined Tags The author of the XML document makes up the tags Definition of the tags are held in a dictionary called the Document Type Definition (DTD) Strict Rules Precise rules are needed to define the structure of the document Processing is made easier with stricter rules Browsing would be much faster if HTML was stricter

URLs and URIs XML documents can live on the Web, just like HTML and other documents. When they do, they are referred to by Uniform Resource Locators (URLs), just like HTML files. For example, at the URL http://www.hypermedic.com/style/xml/ tempest.xml you’ll find the complete text of Shakespeare’s Tempest marked up in XML. Although URLs are well understood and well supported, the XML specification uses Uniform Resource Identifiers (URIs) instead. URIs are a superset of URLs. A URI is a more general means of locating a resource; URIs focus a little more on the resource and a little less on the location. Furthermore, they aren’t necessarily limited to resources on the Internet. For instance, the URI for any Imaginary XML book would be uri:isbn:123456. This doesn’t refer to the specific copy you might be having but it refers to the almost all the books of that particular edition

URNs URNs are not as commonly seen as URLs. In fact, most people, even those who have been on the Internet for years, have never seen a URN. They exist to provide a persistent, location-independent name for a resource. For example, a person's name is similar to a URN, because the person has the same name, no matter where they are. Even after a person dies, the name still refers to the person who used to have it when they were alive. A name is different from a URN, though, because more than one person can have the same name, whereas URNs are designed to be unique across time and space. A URN looks something like this: urn:foo:a123,456 First comes the string urn, upper-or lowercase, and a colon. After the first colon comes the Namespace Identifier, or NID, (foo in this case) followed by another colon. And finally comes the Namespace Specific String, or NSS (a123,456 for example). As you can see from the terminology, URNs were designed with namespaces already in mind. The NID portion of the URN declares what type of URN this is. For example, to create URNs for Canadian citizens, we might declare an NID of Canadian-Citizen. The NSS portion of the URN is the part that must be unique, and persistent. In Canada, all citizens are assigned unique Social Insurance Numbers. So, a URN for a Canadian citizen with a Social Insurance Number of 000-000-000 might look like this: urn:Canadian-Citizen:000-000-000

XLinks and XPointers As long as XML documents are posted on the Internet, people will want to link them to each other. Standard HTML link tags can be used in XML documents, and HTML documents can link to XML documents. For example, this HTML link points to the aforementioned copy of the Tempest in XML: <A HREF=”http://www.hypermedic.com/style/xml/tempest.xml”> The Tempest by Shakespeare </A> However, XML lets you go further with XLinks for linking to documents and XPointers for addressing individual parts of a document. XLinks enable any element to become a link, not just an A element. For example, in XML, the above link might be written like this: <PLAY xlink:type=”simple” xmlns:xlink=”http://www.w3.org/1999/xlink” xlink:href=”http://www.hypermedic.com/style/xml/tempest.xml”> <TITLE>The Tempest</TITLE> by <AUTHOR>Shakespeare</AUTHOR> </PLAY>

Furthermore, XLinks can be bidirectional, multidirectional, or even point to multiple mirror sites from which the nearest is selected. XLinks use normal URLs to identify the site they’re linking to. As new URI schemes become available, XLinks will be able to use those, too. XPointers allow URLs to point not just to a particular document at a particular location, but to a particular part of a particular document. An XPointer can refer to a particular element of a document, to the first, the second, or the seventeenth such element, to the first element that’s a child of a given element, and so on. XPointers provide extremely powerful connections between documents that do not require the targeted document to contain additional markup just so its individual pieces can be linked to from other documents.

XML Applications XML is a meta-markup language for designing domain-specific markup languages. Each specific XML-based markup language is called an XML application . This is not an application that uses XML, such as the Mozilla Web browser, the Gnumeric spreadsheet, or the XML Spy editor; rather, it is an application of XML to a specific field such as the Chemical Markup Language (CML) for chemistry. Each XML application has its own syntax and vocabulary. This syntax and vocabulary adheres to the fundamental rules of XML. This is much like human languages, each of which has its own vocabulary and grammar, while adhering to certain fundamental rules.

Real-World XML Examples Exchanging data between different systems Using Internet search Engines Capturing data from the web Electronic Data Interchange (EDI)

XML Applications Channel Definition Format (CDF) Used in push technology applications Open Financial Exchange (OFX) - now International Financial Exchange (IFX) Standardizes information exchange in the financial sector Mathematical Markup Language (MathML) XML applications for mathematical equations Chemical Markup Language (CML) Organizes complex chemical objects Synchronized Multimedia Integration Language (SMIL) W3C recommendation for writing TV-like multimedia presentations for the Web

Your First XML Document <?xml version=”1.0”?> <FOO> Hello XML! </FOO> The above document is a well-formed XML document. (XML has special terms for documents that it considers “good” depending on exactly which set of rules they satisfy.) The first line of the simple XML document is the XML declaration. The XML declaration has a version attribute. An attribute is a name-value pair separated by an equals sign. The name is on the left side of the equals sign, and the value is on the right side between double quote marks. Every XML document should begin with an XML declaration that specifies the version of XML in use. (Some XML documents omit this for reasons of backward compatibility, but you should include a version declaration unless you have a specific reason to leave it out.) In the previous example, the version attribute says that this document conforms to the XML 1.0 specification. There isn’t any version of XML except 1.0. This attribute just exists to allow the possibility of future revisions. <FOO> Hello XML! </FOO> Collectively these three lines form a FOO element . Separately, <FOO> is a start tag ; </FOO> is an end tag ; and Hello XML! is the content of the FOO element. Divided another way, the start tag, end tag, and XML declaration are all markup . The text Hello XML! is character data .

Assigning Meaning to XML Tags Markup can indicate three kinds of meaning: structural, semantic, or stylistic. Structure specifies the relations between the different elements in the document. Semantics relates the individual elements to the real world outside of the document itself. Style specifies how an element is displayed. Structure merely expresses the form of the document, without regard for differences between individual tags and elements. Semantic meaning exists outside the document, in the mind of the author or reader, or in some computer program that generates or reads these files. For instance, a Web browser that understands HTML, but not XML, would assign the meaning “paragraph” to the tags and but not to the tags <GREETING> and </GREETING>, <FOO> and </FOO>, or <DOCUMENT> and </DOCUMENT>. The third kind of meaning that can be associated with a tag is stylistic. Style says how the content of a tag is to be presented on a computer screen or other output device. Style says whether a particular element is bold, italic, green, two inches high, or what have you.

Writing a Style Sheet for an XML Document XML allows you to create any tags that you need. Of course, since you have almost complete freedom in creating tags, there’s no way for a generic browser to anticipate your tags and provide rules for displaying them. Therefore, you also need to write a style sheet for the XML document that tells browsers how to display particular tags. Like tag sets, style sheets can be shared between different documents and different people, and the style sheets you create can be integrated with style sheets others have written. <?xml version=”1.0”?> <GREETING> Hello XML! </GREETING> The above greeting.xml contains only one tag, <GREETING>, so all you need to do is define the style for the GREETING element.

The following is a very simple style sheet that specifies that the contents of the GREETING element should be rendered as a block-level element in 24-point bold type. GREETING {display: block; font-size: 24pt; font-weight: bold} The above code should be typed in a text editor and saved in a new file called greeting.css The .css extension stands for Cascading Style Sheet. Again, the .css extension is important, although the exact filename is not important.

Attaching a Style Sheet to an XML Document Once you’ve written an XML document and a Cascading Style Sheet for that document, you need to tell the browser to apply the style sheet to the document. In the long-term, there are likely to be a number of different ways to do this, including browser-server negotiation via HTTP headers, naming conventions, and browserside defaults. However, right now the only way that works is to include an <?xml-stylesheet?> processing instruction in the XML document to specify the style sheet to be used. The <?xml-stylesheet?> processing instruction has two required attributes: type and href. The type attribute specifies the style sheet language used, and the href attribute specifies a URL, possibly relative, where the style sheet can be found. <?xml version=”1.0”?> <?xml-stylesheet type=”text/css” href=”greeting.css”?> <GREETING> Hello XML! </GREETING>

Organization of the XML data XML is based on a containment model. Each XML element can contain text or other XML elements called children. A few XML elements may contain both text and child elements. This is called mixed content . However, in data heavy documents it should be avoided. Complete Example of Baseball League Starting the document: XML declaration and root element <?xml version=”1.0”?> <SEASON> </SEASON> The XML declaration is not an element or a tag. Therefore, it does not need to be contained inside the root element SEASON. But every element that you put in this document will go between the <SEASON> start tag and the </SEASON> end tag. This choice of root element means that you will not be able to store multiple seasons in a single file. If you want to do that, however, you can define a new root element that contains seasons.

Major league baseball in the United States is divided into two leagues, the American League and the National League. Each league has a name. The two names can be encoded like this: <?xml version=”1.0”?> <SEASON> <YEAR>1998</YEAR> <LEAGUE> <LEAGUE_NAME>National League</LEAGUE_NAME> </LEAGUE> <LEAGUE> <LEAGUE_NAME>American League</LEAGUE_NAME> </LEAGUE> </SEASON> I’ve chosen to define the name of a league with a LEAGUE_NAME element, rather than simply a NAME element because NAME is too generic and likely to be used in other contexts. For instance, divisions, teams, and players also have names. Each league can be divided into East, West, and Central divisions.

XMLizing player data Each team is composed of players. Each player has a first name and a last name. It’s important to separate the first and last names so that you can sort by either one. The data for the starting pitchers in the 1998 Yankees lineup can be encoded as follows: <TEAM> <TEAM_CITY>New York</TEAM_CITY> <TEAM_NAME>Yankees</TEAM_NAME> <PLAYER> <GIVEN_NAME>Orlando</GIVEN_NAME> <SURNAME>Hernandez</SURNAME> </PLAYER> <PLAYER> <GIVEN_NAME>David</GIVEN_NAME> <SURNAME>Cone</SURNAME> </PLAYER> </TEAM> The tags <GIVEN_NAME> and <SURNAME> are preferable to the more obvious <FIRST_NAME> and <LAST_NAME> or <FIRST_NAME> and <FAMILY_NAME>. Whether the family name or the given name comes first or last varies from culture to culture. Furthermore, surnames aren’t necessarily family names in all cultures.

XMLizing player statistics The next step is to provide statistics for each player. Statistics look a little different for pitchers and batters, especially in the American League where few pitchers bat. Below is Joe Girardi’s 1998 statistics. He’s a catcher so he has batting statistics: <PLAYER> <GIVEN_NAME>Joe</GIVEN_NAME> <SURNAME>Girardi</SURNAME> <POSITION>Catcher</POSITION> <GAMES>78</GAMES> <GAMES_STARTED>76</GAMES_STARTED> <AT_BATS>254</AT_BATS> <HITS>70</HITS> <DOUBLES>11</DOUBLES> <TRIPLES>4</TRIPLES> </PLAYER>

There are several benefits of XML and Among them the most important are :- The data is self-describing. The data can be manipulated with standard tools. The data can be viewed with standard tools. Different views of the same data are easy to create with style sheets. The first major benefit of the XML format is that the data is self-describing. The meaning of each number is clearly and unmistakably associated with the number itself. When reading the document, you know that the 70 in <HITS>70</HITS> refers to hits and not runs batted in or strikeouts. If the person typing in the document inadvertently leaves out a statistic, that doesn’t mean that every number after it is misinterpreted. HITS is still HITS even if the preceding RUNS element is missing.

Attributes In the last chapter, all information was provided either in the form of a tag name or as the text content of an element. This is a straightforward and easy-to-understand approach, but it’s not the only one possible. As in HTML, XML elements may have attributes. An attribute is a name-value pair associated with an element. The name and the value are each strings. You’re already familiar with attribute syntax from HTML. For example, consider this <IMG> tag: <IMG SRC=cup.gif WIDTH=89 HEIGHT=67 ALT=”Cup of coffee”> Attribute syntax fits the baseball example quite nicely. One advantage is that it makes the markup somewhat more concise. For example, instead of containing a YEAR child element, the SEASON element only needs a YEAR attribute: <SEASON YEAR=”1998”> </SEASON> On the other hand, LEAGUE should be a child of the SEASON element rather than an attribute. For one thing, there are two leagues in a season. Anytime there’s likely to be more than one of something, child elements are called for. Attribute names must be unique within an element. Thus, you cannot, for example, write a SEASON element like this:

<SEASON YEAR=”1998” LEAGUE=”National” League=”American”> </SEASON> The second reason LEAGUE is naturally a child element rather than an attribute is that it has substructure; that is, it, itself, is subdivided into DIVISION elements. Attribute values are flat text. XML elements can conveniently encode structure. Attribute values cannot. However, the name of a league is unstructured, flat text; and there’s only one name per league, so LEAGUE elements can easily have a NAME attribute instead of a LEAGUE_NAME child element: <LEAGUE NAME=”National League”> </LEAGUE> Because an attribute is more closely tied to its element than a child element is, you don’t run into problems by using NAME instead of LEAGUE_NAME for the name of the attribute. Divisions and teams can also have NAME attributes without any fear of confusion with the name of a league. Because an element can have more than one attribute (as long as the attributes have different names).

Attributes versus Elements The last code’s no-attribute approach was an extreme position. It’s also possible to swing to the other extreme—storing all the information in the attributes and none in the content. In general, I don’t recommend this approach. Storing all the information in element content is much easier to work with in practice. There are no hard and fast rules about when to use child elements and when to use attributes. Generally, you’ll use whichever suits your application. With experience, you’ll gain a feel for when attributes are easier than child elements and vice versa. Until then, one good rule of thumb is that the data itself should be stored in elements. Information about the data (metadata) should be stored in attributes. And when in doubt, put the information in the elements. To differentiate between data and metadata, ask yourself whether someone reading the document would want to see a particular piece of information. If the answer is yes, then the information probably belongs in a child element. If the answer is no, then the information probably belongs in an attribute. If all tags were stripped from the document along with all the attributes, the basic information should still be present.

Attributes are good places to put ID numbers, URLs, references, and other information not directly or immediately relevant to the reader. However, there are many exceptions to the basic principle of storing metadata as attributes. Reasons for making an exception include: Attributes can’t hold structure well. Elements allow you to include meta-metadata (information about the information about the information). Not everyone always agrees on what is and isn’t metadata. Elements are more extensible in the face of future changes. IMP: CSS styles only apply to element content, not to attributes. If you use CSS, any data that you want to display to the reader should be part of an element’s content rather than one of its attributes.

Where Is XML Used, and Where Can it Be Used? Well, that's quite a question. XML is platform and language independent, which means it doesn't matter that one computer may be using, for example, Visual Basic on a Microsoft operating system, and the other is a UNIX machine running Java code. Really, any time one computer program needs to communicate with another program, XML is a potential fit for the exchange format. Web Site Content The W3C uses XML to write its specifications. These XML documents can then be transformed to HTML for display (by XSLT), or transformed to a number of other presentation formats. Some web sites also use XML entirely for their content, where traditionally HTML would have been used. This XML can then be transformed to HTML via XSLT, or displayed directly in browsers via CSS. In fact, the web servers can even determine dynamically what kind of browser is retrieving the information, and then decide what to do. For example, transform the XML to HTML for older browsers, and just send the XML straight to the client for newer browsers, reducing the load on the server.

Remote Procedure Calls XML is also used as a protocol for Remote Procedure Calls ( RPC ). RPC is a protocol that allows objects on one computer to call objects on another computer to do work, allowing distributed computing Using XML and HTTP for these RPC calls, using a technology called the Simple Object Access Protocol (SOAP) , allows this to occur even through a firewall, which would normally block such calls, providing greater opportunities for distributed computing. E-Commerce E-commerce is one of those buzzwords that you hear all over the place. Companies are discovering that by communicating via the Internet, instead of by more traditional methods (such as faxing, human-to-human communication, etc.), they can streamline their processes, decreasing costs and increasing response times. Whenever one company needs to send data to another, XML is the perfect fit for the exchange format. When the companies involved have some kind of on-going relationship this is known as business-to-business ( B2B ) e-commerce. There are also business to consumer (B2C) transactions–you may even have used this to buy this book if you bought it on the Internet. Both types have their potential uses for XML. Web Server Configurations

The text starting with a "<" character, and ending with a ">" character, is an XML tag. The information in our document (our data) is contained within the various tags that constitute the markup of the document. This makes it easy to distinguish the information in the document from the markup . As you can see, the tags are paired together, so that any opening tag also has a closing tag. In XML parlance, these are called start-tags and end-tags . The end-tags are the same as the start-tags, except that they have a "/" right after the opening < character. In this regard, XML tags work the same as start-tags and end-tags do in HTML. For example, you would mark a section of HTML bold like this: This is bold. As you can see, there is a start-tag, and a end-tag, just like we use for XML. All of the information from the start of a start-tag to the end of an end-tag, and including everything in between, is called an element . So: <first> is a start-tag </first> is an end-tag <first>John</first> is an element Tags and Text and Elements

What are the Pieces that Make Up XML? Structuring information" is a pretty broad topic, and as such it would be futile to try and define a specification to cover it fully. For this reason there are a number of inter-related specifications that all work together to form the XML family of technologies, with each specification covering different aspects of communicating information. Here are some of the more important ones: XML 1.0 is the base specification upon which the XML family is built. It describes the syntax that XML documents have to follow, the rules that XML parsers have to follow, and anything else you need to know to read or write an XML document. It also defines DTDs, although they sometimes get treated as a separate technology. See the next bullet. Because we can make up our own structures and element names for our documents, DTDs and Schemas provide ways to define our document types. We can check to make sure other documents adhere to these templates, and other developers can produce compatible documents

The text between the start-tag and end-tag of an element is called the element content . The content between our tags will often just be data (as opposed to other elements). In this case, the element content is referred to as Parsed Character DATA , which is almost always referred to using its acronym, PCDATA , or with a more general term such as "text content" or even "text node". Rules for Elements Every start-tag must have a matching end-tag, or be a self-closing tag Tags can't overlap XML documents can have only one root element Element names must obey XML naming conventions XML is case-sensitive XML will keep whitespace in your text Element Names If we're going to be creating elements we're going to have to give them names, and XML is very generous in the names we're allowed to use. For example, there aren't any reserved words to avoid in XML, as there are in most programming languages, so we have a lot flexibility in this regard.

However, there are some rules that we must follow: Names can start with letters (including non-Latin characters) or the "_" character, but not numbers or other punctuation characters. After the first character, numbers are allowed, as are the characters "-" and ".". Names can't contain spaces. Names can't contain the ":" character. Strictly speaking, this character is allowed, but the XML specification says that it's "reserved". You should avoid using it in your documents, unless you are working with namespaces. Names can't start with the letters "xml", in uppercase, lowercase, or mixed–you can't start a name with "xml", "XML", "XmL", or any other combination. There can't be a space after the opening "<" character; the name of the element must come immediately after it. However, there can be space before the closing ">"character, if desired. Another important point to keep in mind is that the tags in XML are case-sensitive. Warning! Because XML is case-sensitive, you could legally create an XML document which has both <first> and <First> elements, which have different meanings. This is a bad idea, and will cause nothing but confusion! You should always try to give your elements distinct names, for your sanity, and for the sanity of those to come after you.

Whitespace in PCDATA There is a special category of characters, called whitespace . This includes things like the space character, new lines (what you get when you hit the Enter key), and tabs. Whitespace is used to separate words, as well as to make text more readable. Attributes In addition to tags and elements, XML documents can also include attributes . Why Use Attributes? There have been many debates in the XML community about whether attributes are really necessary, and if so, where they should be used. Here are some of the main points in that debate:

Attributes Can Provide Meta Data that May Not be Relevant to Most Applications Dealing with Our XML For example, if we know that some applications may care about a CD's serial number, but most won't, it may make sense to make it an attribute. This logically separates the data most applications will need from the data that most applications won't need. In reality, there is no such thing as "pure meta data"–all information is "data" to some application. Think about HTML; you could break the information in HTML into two types of data: the data to be shown to a human, and the data to be used by the web browser to format the human-readable data. From one standpoint, the data used to format the data would be meta data, but to the browser or the person writing the HTML, the meta data is the data. Therefore, attributes can make sense when we're separating one type of information from another.

What Do Attributes Buy Me that Elements Don't? Can't elements do anything attributes can do? In other words, on the face of it there's really no difference between: <name nickname='Shiny John'></name> And <name> <nickname>Shiny John</nickname> </name> So why bother to pollute the language with two ways of doing the same thing? The main reason that XML was invented was that SGML could do some great things, but it was too massively difficult to use without a fully-fledged SGML expert on hand. So one concept behind XML is a simpler, kinder, gentler SGML. For this reason, many people don't like attributes, because they add a complexity to the language that they feel isn't needed. On the other hand, some people find attributes easier to use–for example, they don't require nesting and you don't have to worry about crossed tags.

Attributes are Un-Ordered The order of attributes is considered irrelevant. Hence, sometimes you may need to use elements, rather than attributes, for information that must come in the document in a certain order. Why Use Attributes When Elements Look So Much Better? I Mean, Why Use Elements When Attributes Look So Much Better? Many people have different opinions as to whether attributes or child elements "look better". In this case, it comes down to a matter of personal preference and style. In fact, much of the attributes versus elements debate comes from personal preference. Many, but not all, of the arguments boil down to "I like the one better than the other". But since XML has both elements and attributes, and neither one is going to go away, you're free to use both. Choose whichever works best for your application, whichever looks better to you, or whichever you're most comfortable with. Comments Comments provide a way to insert into an XML document text that isn't really part of the document, but rather is intended for people who are reading the XML source itself.

Anyone who has used a programming language will be familiar with the idea of comments: you want to be able to annotate your code (or your XML), so that those coming after you will be able to figure out what you were doing. (And remember: the one who comes after you may be you! Code you wrote six months ago might be as foreign to you as code someone else wrote.) Of course, comments may not be as relevant to XML as they are to programming languages; after all, this is just data, and it's self-describing to boot. But you never know when they're going to come in handy, and there are cases where comments can be very useful, even in data. Comments start with the string , as shown here: <name nickname='Venky K'> <first>Venkat</first> <!—This is a Comment--> <middle></middle> <last>Krishnan</last> </name> There are a couple of points that we need to note about comments. First, you can't have a comment inside a tag. The XML specification states that an XML parser doesn't need to pass these comments on to the application, meaning that you should never count on being able to use the information inside a comment from your application. Comments are only there for the benefit of someone reading your XML markup.

Empty Elements Sometimes an element has no PCDATA. In this case, you also have the option of writing this element using the special empty element syntax : <middle/> This is the one case where a start-tag doesn't need a separate end-tag, because they are both combined together into this one tag. In all other cases, they do. Recall from our discussion of element names that the only place we can have a space within the tag is before the closing ">". This rule is slightly different when it comes to empty elements. The "/" and ">" characters always have to be together, so you can create an empty element like this: <middle /> but not like these: <middle/ > <middle / >

XML Declaration It is often very handy to be able to identify a document as being of a certain type. XML provides the XML declaration for us to label documents as being XML, along with giving the parsers a few other pieces of information. You don't need to have an XML declaration, but it's considered good practice to include it. A typical XML declaration looks like this: <?xml version='1.0' encoding='UTF-16' standalone='yes'?> Some things to note about the XML declaration: The XML declaration starts with the characters <?xml, and ends with the characters ?>. If you include it, you must include the version, but the encoding and standalone attributes are optional. The version, encoding, and standalone attributes must be in that order.

Currently, the version should be 1.0. If you use a number other than 1.0, XML parsers that were written for the version 1.0 specification can reject the document. (If there is ever a new version of the XML Recommendation, the version number in the XML declaration will be used to signal which version of the specification your document claims to support.) The XML declaration must be right at the beginning of the file. That is, the first character in the file should be that "<"; no line breaks or spaces. Some parsers are more forgiving about this than others. So an XML declaration can be as full as the previous one, or as simple as: <?xml version='1.0'?> A character code is a one-to-one mapping between a set of characters and the corresponding numbers to represent those characters. A character encoding is the method used to represent the numbers in a character code digitally (in other words how many bytes should be used for each number, etc.) One character code that you might have come across is the American Standard Code for Information Interchange ( ASCII ). For example, in ASCII the character "a" is represented by the number 97, and the character "A" is represented by the number 65.

Illegal PCDATA Characters There are some reserved characters that you can't include in your PCDATA because they are used in XML syntax, the "<" and "&" characters: <comparison>6 is < 7 & 7 > 6</comparison> This means that the XML parser comes across the "<" character, and expects a tag name, instead of a space. (Even if it had got past this, the same error would have occurred at the "&" character.) There are two ways you can get around this: escaping characters , or enclosing text in a CDATA section . Escaping Characters To escape these two characters, you simply replace any "<" characters with "<" and any "&" characters with "&". (In addition, you can also escape the ">" character with ">". It isn't necessary, but it does make things more consistent, since you need to escape all of the "<" characters.) The above XML could be made well-formed by doing the following: <comparison>6 is < 7 & 7 > 6 </comparison> lt; and & are known as entity references . The following entities are defined in XML: &-the & character <-the < character >-the > character '-the ' character "-the " character

CDATA Sections If you have a lot of "<" and "&" characters that need escaping, you may find that your document quickly becomes very ugly and unreadable. Luckily, there are also CDATA sections. Using CDATA sections, we can tell the XML parser not to parse the text, but to let it all go by until it gets to the end of the section. CDATA sections look like this: <comparison><![CDATA[6 is < 7 & 7 > 6]]></comparison> Everything starting after the <![CDATA[ and ending at the ]]> is ignored by the parser, and passed through to the application as is. The only character sequence that can't occur within a CDATA section is "]]>", since the XML parser would think that you were closing the CDATA section. If you needed to include this sequence, you would be better off keeping it out of the CDATA section, like this: <![CDATA[This text contains the sequence ']]>]]><![CDATA[' in it.]]>

Parsing XML The main reason for creating all of these rules about writing well-formed XML documents is so that we can create a computer program to read in the data, and easily tell markup from information. Apache Xerces The Apache Software Foundation's Xerces sub-project of the Apache XML Project ( http:// xml.apache.org / ) has resulted in XML parsers in Java and C++, plus a Perl wrapper for the C++ parser. These tools are free, and the distribution of the code is controlled by the GNU Public License. James Clark's Expat Expat is an XML 1.0 parser toolkit written in C. More information can be found at http:// www.jclark.com/xml/expat.html and Expat can be downloaded from ftp:// ftp.jclark.com/pub/xml/expat.zip . It is free for both private and commercial use. Xml4j IBM's AlphaWorks site ( http:// www.alphaworks.ibm.com ) offers a number of XML tools and applications, including the xml4j parser. This is another parser written in Java, available for free, though there are some licensing restrictions regarding its use.

Errors in XML As well as specifying how a parser should get the information out of an XML document, it is also specified how a parser should deal with errors in XML. There are two types of error in the XML specification: errors and fatal errors . An error is simply a violation of the rules in the specification, where the results are undefined; the XML processor is allowed to recover from the error and continue processing. Fatal errors are more serious: according to the specification a parser is not allowed to continue as normal when it encounters a fatal error. (It may, however, keep processing the XML document to search for further errors.) This is called draconian error handling . Any error which causes an XML document to cease being well-formed is a fatal error. The reason for this drastic handling of non-well-formed XML is simple: it would be extremely hard for parser writers to try and handle "well-formedness" errors, and it is extremely simple to make XML well-formed. (Web browsers don't force documents to be as strict as XML does, but this is one of the reasons why web browsers are so incompatible; they must deal with all of the errors they may encounter, and try to figure out what the person who wrote the document was really trying to code.)

But draconian error handling doesn't just benefit the parser writers; it also benefits us when we're creating XML documents. If I write an XML document that doesn't properly follow XML's syntax, I can find out right away and fix my mistake. On the other hand, if the XML parser tries to recover from these errors, it may misinterpret what I was trying to do, but I wouldn't know about it because no error would be raised. In this case, bugs in my software would be much harder to track down, instead of being caught right at the beginning when I was creating my data. Even worse, if I sent my XML document to someone else, their parser might interpret the mistake differently.

Namespaces A URI (Uniform Resource Identifier) is a string of characters that identifies a resource. It can come in one of two flavors: URL (Uniform Resource Locator), or URN (Universal Resource Name). How XML Namespaces Work To use XML Namespaces in your documents, elements are given qualified names . (In most W3C specifications "qualified name" is abbreviated to QName .) These qualified names consist of two parts: the local part , which is the same as the names we have been giving elements all along, and the namespace prefix , which specifies to which namespace this name belongs. For example, to declare a namespace called http://sernaferna.com/pers, and associate a <person> element with that namespace, we would do something like the following: <pers:person xmlns:pers="http://sernaferna.com/pers"/> The key is the xmlns:pers attribute ("xmlns" stands for XML NameSpace). Here we are declaring the pers namespace prefix, and the URI of the namespace which it represents (http://sernaferna.com/pers). We can then use the namespace prefix with our elements, as in pers:person.

Document Type Definitions The need to validate documents against a vocabulary is common in markup languages. In fact, it is so common that the creators of XML included a method for checking validity in the XML Recommendation. A document is valid if its XML content complies with a definition of allowable elements, attributes, and other document pieces. By utilizing special Document Type Definition syntaxes, or DTDs, you can check the content of a document type with special parsers. More specifically, DTDs outline the following features within the DTD: The element types that will be allowed within the XML document The various characteristics of each element type, along with the attributes used with each element and the content each element is capable of having Any notations that can be encountered within the document The entities that can be used within the document The XML Recommendation separates parsers into two categories-validating and nonvalidating. Validating parsers, according to the Recommendation, must implement validity checking using DTDs. Therefore, if we have a validating parser, we can remove the content checking code from our application and depend on the external processor. <?xml version="1.0"?> <!DOCTYPE name [ <!ELEMENT name (first, middle, last)> <!ELEMENT first (#PCDATA)> <!ELEMENT middle (#PCDATA)> <!ELEMENT last (#PCDATA)>

]> <name> <first>John</first> <middle>Fitzgerald</middle> <last>Doe</last> </name> Save the file as name1.xml. <!DOCTYPE name [ Immediately following the XML header is the Document Type Declaration , commonly referred to as the DOCTYPE. This informs the parser that there is a DTD associated with this XML Document. If the document contains a DTD the Document Type Declaration must appear at the start of the document (preceded only by the XML header)-it is not permitted anywhere else within the document. The DOCTYPE declaration has an exclamation mark (!) at the start of the element name. Following the name of the root element, you have several options for specifying the rest of the Document Type Declaration. In our <name> example, our element declarations appeared within our XML Document, between the [ and ] of our Document Type Declaration. Any declarations within the XML document, as in our sample, are the internal subset . The XML declaration also allows you to refer to an external DTD. Declarations that appear in an external DTD are the external subset . You can refer to an external DTD in one of two ways System identifiers Public identifiers

System Identifiers A system identifier allows you to specify the physical location of a file on your system. It is comprised of two parts: the keyword SYSTEM followed by a URI reference to a document with a physical location. <!DOCTYPE name SYSTEM "name.dtd" [...]> This can be a file on your local hard-drive, for example, or, perhaps, a file on your intranet or the Internet. To indicate that you are using a system identifier, you must type the word SYSTEM after the name of the root element in your declaration. Immediately following the SYSTEM keyword is the URI reference to the location of the file in quotation marks. Some valid system identifiers include: <!DOCTYPE name SYSTEM "file:///c:/name.dtd" [...]> <!DOCTYPE name SYSTEM "http://sernaferna.com/hr/name.dtd" [...]> <!DOCTYPE name SYSTEM "name.dtd"> Notice that in the last example we have omitted the [ and ]. This is perfectly normal. Specifying an internal subset is optional. You can use an external and internal subset at the same time.

Public Identifiers Public identifiers provide a second mechanism to locate DTD resources. <!DOCTYPE name PUBLIC "-//Wrox Press//DTD Name example from Chapter 1//EN"> Much like the system identifier, the public identifier begins with a keyword, PUBLIC, followed by a specialized identifier. However, instead of a reference to a file, public identifiers are used to identify an entry in a catalog. According to the XML specification, public identifiers can follow any format, however, there is a commonly used format called Formal Public Identifiers , or FPIs . The syntax for FPIs follows the basic structure: -//Owner//Class Description//Language//Version

Try It Out-The External DTD We have alluded to the idea that external DTDs can be very useful. By utilizing an external DTD, we can easily share our vocabulary with others in our industry, or even our own company. By this same logic, we can utilize vocabularies that others have already developed, by referring to external files they have created. Therefore, let's reconfigure our <name> example so that our DTD is defined external to our XML document. EXTERNAL DTD.doc

How It Works In this Try It Out, we used an external DTD to check our XML content. As you may have guessed, the syntax for the DTD changed very little. The main difference between the internal DTD and external DTD was that there was no DOCTYPE declaration within the external DTD. The DOCTYPE declaration is always located within the XML document. In addition, within our name4.xml document there was no internal subset. Instead, we used a public identifier to indicate what DTD our validation program should use. Of course, our validation program has no way to resolve public identifiers. The processor instead used the optional URI reference that we included to find the correct DTD for validation. In this case, our XML parser must find the file identified as "name4.dtd". Because this is a relative URL reference (it does not contain a web site address or drive letter), our parser will begin looking in the current directory-where the XML document it is parsing is located. The XML Recommendation does not specify how parsers should handle relative URL references; however, most XML parsers will treat the path of the XML document as the base path, just as ours has done.

Element Declarations Throughout the beginning of this chapter, we have seen element declarations in use, but have not yet looked at the element declaration in detail. When using a DTD to define the content of an XML document, you must declare each element that appears within the document. As we will soon see, DTDs may also include declarations for optional elements, elements that may or may not appear in the XML document. <!ELEMENT name (first, middle, last)> Element declarations can be broken down into three basic parts: The ELEMENT declaration The element name The element content model As we have seen with the DOCTYPE declaration, the ELEMENT declaration is used to indicate to the parser that we are about to define an element. Much like the DOCTYPE declaration, the ELEMENT declaration begins with an exclamation mark. The declaration can appear only within the context of the DTD.

Immediately following the ELEMENT keyword is the name of the element that you are defining. Just as we saw in the DOCTYPE, the element name must appear exactly as it will within the XML document, including any namespace prefix. The content model of the element appears after the element name. An element's content model defines the allowable content within the element. An element may be empty, or its content may consist of text, element children, or a combination of children and text. This is essentially the crux of the DTD, where the entire document's structure is defined. As far as the XML Recommendation is concerned, there are four kinds of content model: Empty Element Mixed Any To define an element with an empty content model you simply include the word EMPTY following the element name in the declaration: <!ELEMENT br EMPTY> ( in XHTML) There are two fundamental ways of specifying that an element will contain more than one child: Sequences (If the elements should be in distinct order) Choices

Suppose we needed to allow one element or another, but not both. Obviously, we would need a choice mechanism of some sort. For example, let's say we were designing a DTD that could be used to catalog our music library. Within our catalog, we had several <item> elements. Within each <item> element we wanted to allow the four choices <CD>, <cassette>, <record>, and <MP3>. We could declare our <item> element as follows: <!ELEMENT item (CD | cassette | record | MP3)> This declaration would allow our <item> element to contain one <CD> or one <cassette> or one <record> or one <MP3> element. If our <item> element were empty, or if it contained more than one of these elements the parser would raise an error. The choice content model is very similar to the sequence content model. Instead of separating the elements by commas, however, you must use the vertical bar (|) character. The vertical bar functions as an exclusive OR. An exclusive OR allows one and only one element out of the possible choices. When creating our <name> declaration we would need to specify that the content may include either a <fullname> element or the <first>, <middle>, and <last> sequence of elements, but not both. The XML Recommendation allows us to mix sequences and choices. Because of this, we can declare our model as follows: <!ELEMENT name (fullname | (first, middle, last))>

Mixed Content The XML Recommendation specifies that any element with text in its content is a mixed content model element. Within mixed content models, text may appear by itself or it may be interspersed between elements. We have already seen some examples of the simplest mixed content model-text only: <!ELEMENT artist (#PCDATA)> There is only one way to declare a mixed content model within DTDs. In the mixed content model, we must use the choice mechanism when adding elements. This means that each element within our content model must be separated by the vertical bar (|) character: <!ELEMENT p (#PCDATA | b | i)*> In the sample above, we have attempted to describe the element (actually, this definition is horribly lacking-there are many more allowable children of a real element). Notice that we have used the choice mechanism to describe our content model; a vertical bar separates each element. We cannot use commas to separate the choices.

When including elements in the mixed content model, the #PCDATA keyword must always appear first in the list of choices. This allows validating parsers to immediately recognize that it is processing a mixed content model, rather than an element content model. Unlike element-only content models, you are not allowed to have inner content models in a mixed declaration. You should also notice that we have included the '*' outside of the parentheses of our content model. When you are including elements within your mixed content model you are required to include the '*' at the end of your content model. The '*' character is known as a cardinality indicator . To simplify, every time you declare elements within a mixed content model, they must follow four rules: They must use the choice mechanism to separate elements. The #PCDATA keyword must appear first in the list of elements. There must be no inner content models. The '*' cardinality indicator must appear at the end of the model.

Any Content Finally, we can declare our element utilizing the ANY keyword: <!ELEMENT catalog ANY> In the above, the ANY keyword indicates that any elements declared within the DTD may be used within the content of the <catalog> element, and that they may be used in any order any number of times. The ANY keyword does not allow you to include elements in your XML document that are not declared within the DTD. In addition, any character data may appear within the <catalog> element. Because DTDs are used to restrict content, the ANY keyword is not very popular as it does very little to restrict the allowed content of the element you are declaring. Cardinality An element's cardinality defines how many times it will appear within a content model. Each element within a content model may have an indicator of how many times it will appear following the element name. DTDs allow four indicators for cardinality:

Indicates that the element may appear zero or more times. * Indicates that the element may appear one or more times. + Indicates that the element may appear either once or not at all. ? As we have seen in all of our content models thus far, when no cardinality indicator is used it indicates that the element must appear once and only once. This is the default behavior for elements used in content models. [none] Description Indicator

Let's look at these indicators in action: < !ELEMENT parody (title?, artist?)> Suppose we used cardinality indicators when declaring the content for our <parody> element. By including a '?' when specifying our title and artist elements, we inform the processor that these elements may appear once or not at all within our content model. If we were to validate the document again, the parser would not raise validity errors if the <title> element and <artist> elements were missing. With our new declaration, the only allowable <parody> elements include: <parody> <title>Like A Virgin</title> <artist>Madonna</artist> </parody> <parody> <title>Like A Virgin</title> </parody> <parody> <artist>Madonna</artist> </parody><parody> </parody> In each of the above cases, we can see that the <title> element may or may not appear. In addition, the <artist> element may or may not appear. In the final example, we see that the <parody> element can be completely empty, where neither element appears. An important point to remember is that, because we used the '?' cardinality indicator, both the <title> and <artist> elements may appear within our <parody> element at most one time. It is also important to notice that when both elements do appear, they must be in the order that we defined within our sequence.

Attribute Declarations Attribute declarations are in many ways similar to element declarations. Instead of declaring content models for allowable elements, however, DTDs allow you to declare a list of allowable attributes for each element. These lists are called ATTLIST declarations. <!ELEMENT catalog (CD | cassette | record | MP3)*> <!ATTLIST catalog name CDATA #IMPLIED> Above, we have an element declaration for our <catalog> element from our catalog example. Following the element declaration, we have an ATTLIST declaration that declares the allowable attributes of our <catalog> element. This particular ATTLIST declares only one attribute, name, for the <catalog> element. An ATTLIST declaration can be broken down into three basic parts: The ATTLIST keyword The associated element's name The list of declared attributes

Just as we have seen in all of our other declarations, the ATTLIST declaration begins with an exclamation mark to indicate that it is part of the DTD. Immediately following the ATTLIST keyword is the name of the associated element. In our example above, the name of our associated element is catalog. We indicated that we were building a list of attributes for a <catalog> element by including the word catalog immediately following the ATTLIST keyword. Following the ATTLIST name, we declared each attribute in the list. An ATTLIST declaration may include any number of attributes. Each attribute in the list can be broken down into three parts: The attribute name The attribute type The attribute value declaration Let's look at each section of name attribute declaration: name CDATA #IMPLIED In the above declaration, the name of the attribute is, ironically, name. We have declared that our name attribute may contain character data by using the CDATA keyword-this is our attribute's type. Finally, we have declared that our attribute has no default value, and further, that this attribute does not need to appear within our element using the #IMPLIED keyword.

Let's look at an example document: <?xml version="1.0"?> <!DOCTYPE names [ <!ELEMENT names (name)*> <!ELEMENT name (first, middle?, last)> <!ATTLIST name social ID #REQUIRED> <!ELEMENT first (#PCDATA)> <!ELEMENT middle (#PCDATA)> <!ELEMENT last (#PCDATA)> ]> <names> <name social="_111-22-3333"> <first>John</first> <middle>Fitzgerald</middle> <last>Doe</last> </name> <name social="_777-88-9999"> <first>Jane</first> <middle>Mary</middle> <last>Doe</last> </name> </names>

Attribute Value Declarations Within each attribute declaration, you must also specify how the value will appear in the document. Often we will want to provide a default value for our attribute declaration. At times we may simply want to require that the attribute be specified in the document, still other times we may need to require that the value of the attribute be fixed at a given value. Each attribute can be declared with these properties. The XML Recommendation allows us to specify that the attribute: Has a default value Has a fixed value Is required Is implied Sometimes we need to provide a value for an attribute even if it hasn't been included in the XML document. By specifying a default value for our attributes, we can be sure that it will be included in the final output. As the document is being processed, a validating parser will automatically insert the attribute with the default value if the attribute has been omitted. If the attribute has been included in the document, the parser will use the included attribute.

There are some circumstances where an attribute's value must always be fixed. When an attribute's value can never change we use the #FIXED keyword followed by the fixed value . Fixed values operate much like default values. As the parser is validating the file, if the fixed attribute is encountered then the parser will check that the fixed value and attribute value match. If they do not match, the parser will raise a validity error. If the parser does not encounter the attribute within the element, it will insert the attribute with the fixed value. When you specify that an attribute is required , it must be included within the XML document. Often a document must have the attribute to function properly, at other times it is simply a matter of exercising control over the document content. Imagine you are developing a program that can display images. Within your XML document, you have <image> elements that refer to external image files. In order for your application to display the images, it needs to know what kind of image is being referenced; and without this information, the file cannot be displayed.

Entities An entity is a powerful XML tool that allows DTD and document developers to associate a text alias with non-ASCII text or binary resources and large or frequently used blocks of text and markup. Document Type Definitions (DTDs) that take advantage of the entity mechanism are well organized, easier to read and work with, and able to support literally thousands of nonstandard characters. Without entities, binary resources, such as image and audio files, cannot be included in Extensible Markup Language (XML) documents.

Placing A Character Entity In A Document To use special reserved characters within a document, you need to use a character entity that has already been defined within the XML standard. For example, if you want to use the ampersand sign (&) in the name of a company, you need to specify the XML character entity that represents the ampersand, because the ampersand is used to specify built-in character entities. Entities that represent reserved characters always start with an ampersand, are followed by the entity name, and are closed by adding a semicolon to the end of the entity name. No additional white space is permitted around or inside the entity. To specify a built-in entity, place the following code within the content of your XML document: & This code can be used anywhere within the content of an XML document, for example: Welcome to the Diggins & Kirk Consulting Firm! The content, once processed, would display as follows: Welcome to the Diggins & Kirk Consulting Firm!

Creating Your Own Entity To create your own entities to specify groups of character data, you must first declare them in your DTD or within the beginning of your XML document as you do with elements and attributes. The name of the entity can be made up of letters, digits, periods, dashes, underscores, or a colon and must begin with a letter or an underscore. The value of the entity, called the entity definition, must be enclosed in quotes and can contain any valid markup. The syntax of an entity declaration is the entity element !ENTITY , the name of the entity, and then the entity declaration. To define an entity that specifies the city and state, Anchorage, Alaska, include the following code in your XML document or within your DTD: <!ENTITY AK "Anchorage, Alaska">

Using The Entity You Have Declared Once you have declared an entity, you can place it anywhere within the content of the XML document. The entity reference must start with an ampersand (&), include the entity name, and end with a semicolon (;). Case is important, so if you’ve defined an entity in uppercase, you must also use uppercase when you place the entity notation in the document. To place the previously defined entity in your document, use the following code where you want the entity value to display within the content: Kirk Consulting is located in beautiful downtown &AK; This would be processed through the XML processor and displayed within the XML application accordingly: Kirk Consulting is located in beautiful downtown Anchorage, Alaska.

DTD Limitations They allow us to validate our content without application specific code, allow us to supply default values for attributes, and even create modular XML documents. Throughout your XML career, you will use existing DTDs and often design your own. Because of XML's strong SGML foundation, much of the early XML development focused on the markup of technical documents. Since that time, XML has been used in areas no one ever expected. While this was a great achievement for the XML community, it began to reveal some limitations of DTDs. Some limitations of DTDs include: DTD syntax is different from XML syntax Poor support for XML namespaces Poor data typing Limited content model descriptions

DTD Syntax The DTD syntax is different from the generic XML syntax we learned in the first few chapters. Why is the syntax so different? Early on, we learned that XML is based on SGML. Because many of the developers turning to XML used SGML, the creators of XML chose to adopt the DTD syntax that was originally developed for SGML. This proved to be both a benefit and a limitation within XML. Initially this made migration from SGML to XML a snap. Many users had already developed DTDs for their SGML documents. Instead of having to completely redesign their vocabularies, they could reuse what they had already done with minimal changes. As support for XML grew, new XML tools and standards were developed that allowed users to manipulate their XML data. Unfortunately, these tools were meant for generic XML, not for DTDs.

XML Namespaces Whenever element or attribute names are declared the namespace prefix and colon must be included in the declaration. In addition, DTDs must treat namespace declarations as attributes. This is because the completion of the XML Recommendation occurred before the syntax for XML namespaces was finalized. Forcing users to declare namespace prefixes in advance defeats the purpose of namespaces altogether. Merging documents from multiple namespaces when the prefixes are predefined can be hazardous as well.

Data Typing As XML developers began using DTDs to model more complex data (such as databases and programming objects) the need for stronger data types emerged. Within DTDs the only available data types are limited to use in attribute declarations, and even then provide only a fraction of the needed functionality. There is no method for constraining the data within a text-only element to a specific type. For example, if you were modeling a database and needed to specify that data within a specific element needed to be numeric, you couldn't use DTDs.

Limited Content Model Descriptions In addition to needing more advanced data types, limitations in content model descriptions soon became apparent. Developers wanted the capability to mimic object inheritance in their XML content models. Developers also found the cardinality operators limiting. DTDs lack strict control on the number of times an element occurs.

<!ATTLIST image format NOTATION (jpeg | gif | bmp) #REQUIRED> In the example above, we have specified that the format attribute must appear within the <image> element in the document. If our parser encounters an <image> element without a format attribute as it is processing the document it will raise an error. In most cases the attribute you are declaring won't be required, and often won't even have a default or fixed value. In these circumstances, the attribute may or may not occur within the element. These attributes are called implied attributes , as there is sometimes no explicit value available. When the attributes do occur within the element, a validating parser will simply check that the value specified within the XML document follows the rules for the declared attribute type

INCLUDE and IGNORE The CDATA marked section is a special case of the more general marked section construct provided by SGML Within the body of a DTD (but not within the body of a document), two other kinds of marked section are possible: an IGNORE marked section, and an INCLUDE marked section. As the names suggest, material within an IGNORE marked section is ignored during processing, while material within an INCLUDE marked section is included. These can be used to include and exclude portions of a DTD selectively, so as to adjust it to relevant circumstances.

Suppose, for example, that we want to allow for poems which contain either only stanzas, or only couplets. A content model to enforce this rule is easy to define, but it does require us to to declare both possibilities — we must provide declarations for both <stanza> and <line> elements, even though in a given document we know that only one will appear. An alternative approach might be to provide two different declarations for <poem> , as follows: <![INCLUDE[ <!ELEMENT poem (stanza+)> <!ELEMENT stanza (line+)> ]]> <![IGNORE[ <!ELEMENT poem (couplet+)> <!ELEMENT couplet (line,line)> ]]> The first declaration here will be the one used, since it is within an INCLUDE marked section. The second one will be ignored.

XML Schemas In 1999, the W3C began to develop XML Schemas in response to the growing need for a more advanced format for describing XML documents. Already, work had begun on several efforts that were intended to better model the types of document that were being created by XML developers. The W3C's effort took the best of these early technologies and then added additional features that could be used to fully describe any well-formed XML document So, what is a schema? A schema is any type of model document that defines the structure of something. In this case, our "something" is an XML document. Many of you may have dealt with database schemas–the documents that are used to define the structure of the database tables and fields. In fact, DTDs are forms of schemas. Throughout this book, we have been using the term "vocabulary" where we could have used the word "schema". So, what is an XML Schema? This is where it gets confusing. The term XML Schema is used to refer to the specific W3C XML Schema technology. W3C XML Schemas, much like DTDs allow you to describe the structure for an XML document. Properly, when referring to this technology, you should capitalize the "S" in "Schema". XML Schema definitions are also commonly referred to as XSD.

Benefits of XML Schemas At this point, you already have invested time in learning DTDs. You know the syntax and can create complex, even modular, definitions for your vocabulary. Although XML Schemas are the next great thing, it may be helpful for you to understand some of the benefits of XML Schemas before jumping in. XML Schemas are created using XML, not an alternative SGML syntax XML Schemas fully support the Namespace Recommendation XML Schemas allow you to validate text element content based on built-in and user-defined data types. XML Schemas allow you to more easily create complex and reusable content models XML Schemas allow you to model concepts such as object inheritance and type substitution Let's look at some of these in more detail.

XML Schemas Use XML Syntax The syntax, as we learned, doesn't follow the basic rules for XML well-formedness. Instead, you must declare your DTDs using a separate syntax. When defining an XML Schema, the syntax is entirely in XML; although you still have to learn the rules for which elements and attributes are required in given declarations, you can use XML tools that have no understanding of the rules to process XML Schema documents. As we learn new XML technologies through this book, we will see how to apply them to any XML document. Unfortunately, powerful tools, such as XSLT, often cannot be used on DTDs. XML Schema Namespace Support Because XML Schemas were finalized after the Namespace Recommendation, the concept of namespaces was available to be included in the design. Unlike DTDs, which do not support the full functionality of namespaces, XML Schemas enable you to define vocabularies that utilize namespace declarations. More importantly, XML Schemas allow you to mix namespaces in XML documents with less rigidity. For example, when designing an XML Schema, it is not necessary to specify namespace prefixes, as you must in DTDs. Instead, the XML Schema leaves that decision to the end-user.

XML Schema Datatypes When we were developing our DTDs, we could specify that an element had mixed element, or empty content. Unfortunately, when our elements contained only text we could not exercise any constraints on the type of data that was allowed. Attribute declarations gave us more control, but even then, our types were very limited. Important : XML Schema divides data types into two broad categories: simple and complex. Elements that may contain attributes or other elements are complexTypes . Attributes values and elements that contain only text content are simpleTypes . XML Schemas allow you to specify the type of textual data allowed within attributes and elements using simpleType declarations. By utilizing these types, for example, you could specify that an element may contain only dates, or only positive numbers, or numbers within a certain range. Many commonly used simpleTypes are built into XML Schemas. This is, perhaps, the single most important feature within XML Schemas. By allowing you to specify allowable type of data within an element, you can more rigidly control documents that are intended to represent databases, programming languages, and objects within programming languages.

XML Schema Content Models In order to reuse a content model within a DTD we had to utilize parameter entities. As we saw, this can lead to situations that make it difficult to reuse parts of the DTD. XML Schemas provide several mechanisms for reusing content models. In addition to the simple models we created in DTDs, XML Schemas can model complex programming concepts like type inheritance and element substitution. The advanced features of XML Schemas allow you to build content models upon content models, modifying the definition in each step Basic XML Schemas As we progress through this chapter, you should begin to see more benefits of XML Schemas, which provide many features that were never possible using DTDs The XML Schema Document Although most XML Schemas are stored within a separate XML document, the XML Schema Recommendation takes great pains to ensure that the XML Schema can be defined using alternate methods as well. In this respect, XML Schemas function very similarly to external DTDs, an XML document contains a reference to the XML Schema that defines its vocabulary. An XML document that adheres to a particular XML Schema is an XML Schema instance document.

Try It Out–What's in a Name? In this example, we will create an XML Schema that defines our name vocabulary. We will also see how to refer to the XML Schema from the instance document. At the end of this example, we will break down each step to see how it works. WHATS N A NAME.doc

How It Works In this Try It Out example, we created an XML Schema for our name vocabulary. We used the XML Schema to check if our instance document was schema valid. In order to connect the two documents we included a reference to the XML Schema within our instance document. The internal process by which schema validators compare the document structure against the vocabulary varies greatly. At the most basic level, the schema validator will read the declarations within the XML Schema. As it is parsing the instance document, it will validate each element that it encounters against the matching declaration. If it finds an element or attribute that does not appear within the declarations, or if it finds a declaration that has no matching XML content it will raise a schema validity error. Let's break the XML Schema down into smaller pieces so that we can see some of what we will be learning later: <?xml version="1.0"?> As we have seen in all of our XML documents, we begin with the XML declaration. Again, this is optional but it is highly recommended that you include it to avoid XML version conflicts later. <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace="http://www.wrox.com/name" xmlns:target="http://www.wrox.com/name" elementFormDefault="qualified">

The root element within our XML Schema is the <schema> element. Within the <schema> element, we have our namespace declaration. We indicated that the namespace of our <schema> element is http://www.w3.org/2001/XMLSchema . This namespace represents the Recommendation version of XML Schema. Within the <schema> element, we have also included a targetNamespace attribute that indicates that we are developing a vocabulary for the namespace http:// www.wrox.com /name . Remember this is just a unique name that we chose, the URL does not necessarily point to anything. We also declared a namespace that matches our targetNamespace with the prefix target. If we need to refer to any declarations within our XML Schema we will need this declaration, so we have included it just in case. Again, you are not required to use target as your prefix, you could choose any prefix you like. We also included the attribute elementFormDefault with the value qualified. Essentially, this controls the way namespaces are used within our corresponding XML document. For now, it is best to get into the habit of adding this attribute with the value qualified, as it will simplify our XML documents.

<element name="name"> Within our <schema> element, we have an <element> declaration. Within this <element> declaration, we specified that the name of the element is name. In this example, we have chosen to specify our content by including a <complexType> definition within our <element> declaration. <complexType> <sequence> <element name="first" type="string"/> <element name="middle" type="string"/> <element name="last" type="string"/> </sequence> <attribute name="title" type="string"/> </complexType> Because our <name> element, in our example, contains the elements <first>, <middle>, and <last> it is considered a complexType. Our <complexType> definition allows us to specify the allowable elements and their order. Just as we did in our DTD, we must declare our content using a content model. In DTDs we could use sequences and choices when specifying our content model.

In our example, we have indicated that we are using a sequence by including a <sequence> definition. Our <sequence> declaration contains three <element> declarations. Within these declarations, we have specified that their type is string. This indicates that the elements must adhere to the XML Schema simpleType string, which allows any textual content. In addition, within our <complexType> definition, we included an <attribute> declaration. This <attribute> declaration appears at the end of the <complexType> definition, after any content model information. By declaring a title attribute, we can easily specify how we should address the individual described by our <name> XML. Before we move on, let's just take a quick look at our instance document: <name xmlns="http://www.wrox.com/name" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.wrox.com/name name5.xsd" title="Mr."> Within the root element of our instance document, we have two namespace declarations. The first indicates that our default namespace is http:// www.wrox.com /name .

This namespace matches the targetNamespace that we declared within our XML Schema. We also declare the namespace http://www.w3.org/2001/XMLSchema-instance . The XML Schema Recommendation allows you to include several attributes from this namespace within your instance document. Our instance document includes the attribute schemaLocation. This attribute tells our schema validator where to find our XML Schema document for validation. The schemaLocation attribute is declared within the namespace http://www.w3.org/2001/XMLSchema-instance so we have prefixed the attribute with the prefix xsi. The value of schemaLocation attribute is http:// www.wrox.com /name name5.xsd. This is known as a namespace/file location pair; it is the namespace of our XML document and the URL of the XML Schema that describes our namespace. The XML Schema Recommendation allows you to declare several namespace/file location pairs within a single schemaLocation attribute–simply separate the values with whitespace. This is useful when your XML document uses multiple namespaces. The schemaLocation attribute is only a hint for the processor to use–the processor may not use the provided location at all. For example, the validator may have a local copy of the XML Schema that it uses, instead of loading the file specified, in order to decrease processor usage. If your XML Schema has no targetNamespace you must refer to the XML Schema using the noNamespaceSchemaLocation attribute within our instance document.

<schema> As we have already seen, the <schema> element is the root element within an XML Schema. The <schema> element allows us to declare namespace information as well as defaults for declarations throughout the document. The XML Schema recommendation also allows us to include a version attribute that can help to identify the XML Schema and the version of our vocabulary. <schema targetNamespace="URI" attributeFormDefault="qualified or unqualified“ elementFormDefault="qualified or unqualified" version="version number"> The XML Schema Namespace In our first example, we declared the namespace http://www.w3.org/2001/XMLSchema within our <schema> element. This allows us to indicate that the <schema> element is part of the XML Schema vocabulary. Remember, because XML is case-sensitive, namespaces are case-sensitive. If the namespace does not match http://www.w3.org/2001/XMLSchema the schema validator should reject the document. For example, you could use any of the following <schema>: <schema xmlns="http://www.w3.org/2001/XMLSchema"> <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xsd:schema xmlns:xsd="http://www.w3.org/2001/XMLSchema"> As we learned the namespace prefix is insignificant–it is only a shortcut to the namespace declaration. You will usually see one of these three variations. The XML Schema Recommendation, itself, uses the prefix xs. Which you use is a matter of personal preference.

Target Namespaces The primary purpose of XML Schemas is to declare vocabularies. These vocabularies can be identified by a namespace that is specified in the targetNamespace attribute. It is important to realize that not all XML Schemas will have a targetNamespace. Many XML Schemas define vocabularies that will be reused in another XML Schema, or vocabularies that will be used in documents where the namespace is not necessary. When declaring a targetNamespace, it is important to include a matching namespace declaration. Like the XML Schema namespace, you can choose any prefix you like, or you can use a default namespace declaration. The namespace declaration will be used when you are referring to declarations within the XML Schema. We will see what this means in more detail later in the section " Referring to an Existing Global Element ". Some possible targetNamespace declarations include: <schema xmlns= http://www.w3.org/2001/XMLSchema targetNamespace= http://www.wrox.com/name xmlns:target="http://www.wrox.com/name"><xs:schema xmlns:xs= http://www.w3.org/2001/XMLSchema targetNamespace= http://www.wrox.com/name xmlns="http://www.wrox.com/name">

Declaration Defaults The <schema> element also allows us to modify the defaults for the declarations that appear within the XML Schema. We can modify these defaults by including the attributes: elementFormDefault attributeFormDefault The elementFormDefault and attributeFormDefault attributes allow you to control the default qualification form for elements and attributes in the instance documents. Within the instance document, elements and attributes may be qualified or unqualified. An element or attribute is qualified if it has an associated namespace URI. For example, the following elements are qualified: <name xmlns="http://www.wrox.com/name"> <first>John</first> <middle>Fitzgerald</middle> <last>Doe</last> </name> <n:name xmlns:n="http://www.wrox.com/name"> <n:first>John</n:first> <n:middle>Fitzgerald</n:middle> <n:last>Doe</n:last> </n:name> Even though our first example doesn't have a namespace prefix, it still has an associated namespace URI, http:// www.wrox.com /name , so it is qualified but not prefixed. Each of the children elements is also qualified because of the default namespace declaration in the <name> element. Again, these elements have no prefixes. In the second example, all of the elements are qualified and prefixed.

Unqualified elements have no associated namespace. For example: <n:name xmlns:n="http://www.wrox.com/name"> <first>John</first> <middle>Fitzgerald</middle> <last>Doe</last> </n:name> The <name> element is qualified, but the <first>, <middle>, and <last> elements are not. The <first>, <middle>, and <last>elements have no associated namespace declaration (default or otherwise) and, therefore, they are unqualified. This mix of qualified and unqualified elements may seem strange; nevertheless, it is the default behavior. The default value for both elementFormDefault and attributeFormDefault is unqualified. Even though the value of the elementFormDefault attribute is unqualified, some elements must be qualified regardless. For example, the <name> element must always be qualified in the instance document. This is because it was declared globally within our XML Schema. In the above example, this is exactly what we have done. We have qualified the <name> element with a namespace but not the <first>, <middle>, and <last> elements. Most of your documents should qualify all of their elements. In some cases, you will need to create a document that uses both qualified and unqualified elements. For example, XSLT and SOAP documents may contain both qualified and unqualified elements. Therefore, it is considered best practice that, unless you have a very specific need to mix qualified and unqualified elements, you should always include the elementFormDefault attribute with the value qualified.

<element> When declaring an element, we are actually performing two primary tasks: specifying the element name and defining the allowable content. <element name="name of the element“ type="global type“ ref="global element declaration“ form="qualified or unqualified" minOccurs="non negative number" maxOccurs="non negative number or 'unbounded'" default="default value“ fixed="fixed value"> According to the XML Schema recommendation, an element's allowable content is determined by its type . As we have already seen, element types are divided into simpleTypes and complexTypes. XML Schemas allow you to specify an element's type in one of three ways: Creating a local type Using a global type Referring to an existing global element In addition to these two methods, you may also reuse elements by referring to an existing global element. In this case, you include a reference to the global element declaration. Of course, you do not need to specify a type in your reference; the type of the element is included in the global element declaration.

Global vs. Local Before we can understand these different methods for declaring elements, we must learn the difference between global and local declarations. XML Schema declarations can be divided into two broad categories: global declarations and local declarations. Global declarations are declarations that appear as direct children of the <schema> element. Global element declarations can be reused throughout the XML Schema. Local declarations do not have the <schema> element as their direct parent and are only valid in their specific context. Let's look at our first example again: <?xml version="1.0"?> <schema xmlns="http://www.w3.org/2001/XMLSchema" targetNamespace= http://www.wrox.com/name xmlns:target="http://www.wrox.com/name"elementFormDefault="qualified">  <element name="name"> <complexType> <sequence>

<element name="first" type="string"/> <element name="middle" type="string"/> <element name="last" type="string"/> </sequence> <attribute name="title" type="string"/> </complexType> </element> </schema> In this XML Schema, we have four element declarations. The first declaration, our <name> element, is a global declaration because it is a direct child of the <schema> element. The declarations for the <first>, <middle>, and <last> elements are considered local because the declarations are not direct children of the <schema> element. The declarations for the <first>, <middle>, and <last> elements are only valid within the <sequence> declaration–they cannot be reused elsewhere in the XML Schema.

Creating a Local Type Of the three methods of element declaration, creating a local type should seem the most familiar. We used this model when we declared our <name> element in our example. To create a local type, you simply include the type declaration as a child of the element declaration: <element name="name"> <complexType>  </complexType> </element> or: <element name="name"> <simpleType>  </simpleType> </element> In these examples, we see that an element declaration may contain a <complexType> definition or a <simpleType> definition. We will look at the insides of these declarations a little later.

Using a Global Type Often, many of our elements will have the same content. Instead of declaring duplicate local types throughout our schema, we can create a global type. Within our element declarations, we can refer to a global type by name. In these examples, our element declaration refers to a global type named string. This type is a member of the XML Schema vocabulary. When referring to the type we must include the namespace prefix, just as we would for elements: <schema xmlns="http://www.w3.org/2001/XMLSchema"> <element name="first" type="string"/> In our first declaration, the XML Schema namespace is the default namespace; because there is no prefix, we do not need a prefix when referring to the string type. <xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="first" type="xs:string"/> In the second declaration, however, the XML Schema namespace is declared using the prefix xs. Therefore, in order to refer to the string type, we must include the namespace prefix xs.

Try It Out–Creating Reusable Global Types Creating global types within our XML Schema is straightforward. Let's convert our <name> example to use a named global type rather than a local type. 28FEB05\creating reusable global types.doc

How It Works We had to make minor modifications to our schema in order to create a reusable complexType. First, we moved our <complexType> definition from within our <element> declaration to our <schema> element. Remember, a declaration is global if it is a direct child of the <schema> element. Once we had made our <complexType> definition global, we needed to add a name attribute so that we could refer to it later. We named our <complexType> definition NameType so it would be easy to identify later. Once we declared our NameType <complexType>, we modified our <name> element declaration to refer to it. We added a type attribute to our element declaration with the value target:NameType. Keep in mind; we had to include the namespace prefix target when referring to the type, so the validator knew what namespace it should look in.

Referring to an Existing Global Element Referring to global types allows us to easily reuse content model definitions within our XML Schema. Often, we may want to reuse entire element declarations, instead of just the type. XML Schemas allow you to reuse global element declarations within your content model. To refer to a global element declaration, simply include a ref attribute and specify the name of the element as the value. <element ref="target:first"/> Again, the name of the element must be qualified with the namespace prefix. Notice that when we refer to a global element declaration we have no type attribute and no local type declaration. Our element declaration will use the type of the <element> declaration to which we are referring.

Try It Out–Referring to Global Element Declarations Let's modify our last example so that we can see how to create and refer to global element declarations. 28FEB05\Referring to Global Element Declarations.doc

How It Works In this Try It Out, we utilized references to global element declarations within our content model. First, we moved the declarations for our <first>, <middle>, and <last> elements from within our <complexType> definition to our <schema> element making them global. After we created our global declarations, we inserted references to the elements within our <complexType>. In each reference, we prefixed the global element name with the prefix target. At this point, it might help to examine what our schema validator is doing in more detail. As our schema validator is processing our instance document, it will first encounter the root element, in this case <name>. When it encounters the <name> element, it will look it up in the XML Schema. When attempting to find the declaration for the root element, the schema validator will only look through the global element declarations. Important In this case, there are four global element declarations: <first>, <middle>, <last>, and <name>. Any one of these could be used as the root element within an instance document; in our example, we are using the <name> element as our instance document root element.

Although the XML Schema Recommendation allows us to have multiple global <element> declarations, we are still only allowed to have one root element in our instance document.Once the schema validator finds the matching declaration, it will find the associated type (in this case it is a global <complexType> definition NameType). It will then validate the content of the <name> element within the instance against the content model defined in the associated type. When the schema validator encounters the <element> reference declarations, it will import the global <element> declarations into the <complexType> definition, as if they had been included directly. Now that we have seen some of the basics of how elements are declared, let's look briefly at some of the features element declarations offer. Later in the chapter, we will look at complexType definitions and content models in more depth.

Cardinality Ae learned that when we are specifying elements in our content models we could modify their cardinality. Cardinality represents the number of occurrences of a specific element within a content model. In XML Schemas, we can modify an element's cardinality by specifying the minOccurs and maxOccurs attributes within the element declaration. Important It is important to note that the minOccurs and maxOccurs attributes are not permitted within global element declarations. Instead, you should use these attributes within the element references in your content models. Within DTDs, we had very limited options when specifying cardinality. Using cardinality indicators, we could declare that an element would appear once and only once, once or not at all, one or more times, or zero or more times. This seems to cover the basics, but many times we need more control. XML Schemas improved the model by allowing you to specify the minimum and maximum separately.

Some possible uses of the minOccurs and maxOccurs attributes include: <element name="element1" type="string" minOccurs="2" maxOccurs=“ 2"/><element ref="target:element2" maxOccurs="10"/ ><element name="element3" type="string" minOccurs="0" maxOccurs="unbounded"/> The default value for the minOccurs attribute is 1. The default value for the maxOccurs attribute is also 1. You can use the two attributes separately or in conjunction. Both attributes accept numbers that are not negative for their value. The maxOccurs attribute also allows the value unbounded, which indicates that there is no limit to the number of occurrences. The only additional rule you must adhere to when specifying minOccurs and maxOccurs, is that the value of maxOccurs must be greater than, or equal to, the value for minOccurs. In our first example above we have declared that the element <element1> must appear within our instance document a minimum of two times and a maximum of two times. In the second example, we have declared our element using a reference to the global <element2> declaration. Even though it is declared using the ref attribute, we are permitted to use the minOccurs and maxOccurs attributes to specify the element's cardinality. In this case, we have included a maxOccurs attribute with the value 10. We have not included a minOccurs attribute, so a schema validator would use the default value, 1. In the final example, we have specified that <element3> may or may not appear within our instance document because the minOccurs attribute has the value 0. We have also indicated that it may appear an infinite number of times because the value of maxOccurs is unbounded.

Default and Fixed Values In XML Schemas, we can declare default and fixed values for elements as well as attributes. When declaring default values for elements we must specify a default text value. You are not permitted to specify a default value for an element whose content model will contain other elements, unless the content model is mixed. When working with DTDs, we saw that we could provide a value for an attribute even if it wasn't included in the XML document. In XML Schemas, we can provide default values for attributes and elements. By specifying a default value for our element, we can be sure that the schema validator will treat the value as if it were included in the XML document, even if it is omitted. To specify a default value, simply include the default attribute with the desired value. Suppose our <name> elements were being used to design the "Doe" family tree. We might want to make "Doe" the default for the last name element: <element name="last" type="string" default="Doe"/> In this example we have declared that our element <last> will have the default value "Doe". Because of this, when a schema validator encounters the last element, if there is no content, it will insert the default value.

For example, if the schema validator encounters: <last></last> or: <last/> it would treat the element as follows: <last>Doe</last> It is important to note that the element must appear within the document, and it must be empty. If the element does not appear within the document, or if the element already has content, the default value will not be used. Again, in XML Schemas elements and attributes may have fixed values. There are some circumstances where you may want to make sure that an element's value does not change, such as an element whose value is used to indicate a version number. When an element's value can never change, simply include a fixed attribute with the fixed value. As the schema validator is processing the file, if an element whose declaration contains a fixed value is encountered, then the parser will check that the content and fixed attribute value match.

If they do not match, the parser will raise a schema validity error. If the element is empty, then the parser will insert the fixed value. To specify a fixed value, simply include the fixed attribute with the desired value: <element name="version" type="string" fixed="1.0"/> In the above example, we have specified that the <version> element, if it appears, must contain the value 1.0, which is a valid string value (the type of our <version> element is string). The following elements would be legal : <version>1.0 </version><version></version> <version/> As the schema validator is processing the file, it will accept the latter of these examples. Because they are empty elements, it will treat them as if the value 1.0 had been included. The following value is not legal : <version>2.0</version> When specifying fixed or default values you must ensure that the value you specify is allowable content for the type that you have declared for your element declaration. Again, your default and fixed values are not permitted to contain element content. Therefore, your element must have a simpleType or a mixed content declaration. You are not permitted to use default and fixed values at the same time within a single element declaration.

<group> Within our XML Schema, we can declare our elements within <complexType> definitions as we have done. However, XML Schemas also allow you to define reusable groups of elements. By creating a global <group> declaration, you can easily reuse and combine entire content models. <group name="name of global group"> Just as we have seen with global <complexType> definitions, all global <group> declarations must be named. Simply specify the name attribute with the desired name. Again, the name that you specify must follow the rules for XML names and it should not include a prefix. The basic structure of a global <group> declaration follows: <group name="NameGroup">  </group>

Try It Out–Using a Global Group Let's redesign our schema so that we can create a reusable global <group> declaration. 28FEB05\Using a global group.doc

How It Works In this Try It Out, we have modified our XML Schema to use a global <group> declaration. First, we created a global <group> declaration named NameGroup. Within our declaration, we specified the allowable content model for our <name> element. Within the <complexType> definition for our <name> element, instead of including element declarations, we created a <group> reference declaration. When referring to the global <group> declaration, we included a ref attribute with the value target:NameGroup. Notice that our <attribute> declaration still appeared within our <complexType> definition and not within our <group> declaration. This should give you some indication of the difference between a <group> and a <complexType> definition. A <complexType> definition defines the allowable content for a specific element or type of element. A <group> declaration simply allows you to create a reusable group of elements, which can be used within content model declarations in your XML Schema. As our schema validator is processing our instance document, it will process the <name> element similarly to our earlier examples. When it encounters the <name> element, it will look it up in the XML Schema. Once it finds the declaration, it will find the associated type (in this case it is a local <complexType> definition). When the schema validator encounters the <group> reference declaration, it will treat the items within the group as if they had been included directly within the <complexType> definition.

Content Models We have already seen that we can use <complexType> and <group> declarations to specify an element's allowable content. XML Schemas provide greater flexibility than DTDs when specifying an element's content model. In XML Schemas you can specify an element's content model using A <sequence> declaration A <choice> declaration A reference to a global <group> declaration An <all> declaration Using these four primary declarations we can specify the content model of our type in a variety of ways. Each of these declarations may contain: Inner content models Element declarations Element wildcards

<sequence> Just as we saw in our DTD content models, specifying our content model using a sequence of elements is very simple. In fact, our first example used a <sequence> declaration when defining the allowable children of our <name> element. <sequence minOccurs="non negative number" maxOccurs="non negative number or 'unbounded'"> The <sequence> declaration allows you to specify minOccurs and maxOccurs attributes that apply to the overall sequence. You can modify the cardinality, or how many of this sequence of elements will occur, by changing the values of these attributes. The minOccurs and maxOccurs attributes function exactly as they did within our element declarations. We have already seen that the <sequence> declaration may contain <element> declarations within it. In addition to <element> declarations, it may contain element wildcards or inner <sequence>, <choice>, or <group> references. We may have sequences within sequences within sequences, or we may have choices within sequences that are in turn within groups–almost any combination you can imagine.

A sample sequence might appear as: <complexType> <sequence> <element name="first" type="string"/> <element name="middle" type="string"/> <element name="last" type="string"/> </sequence> <attribute name="title" type="string"/> </complexType> By utilizing a <sequence> to specify your content model, you indicate that the elements must appear within your instance document in the sequence , or order, specified. For example, because our complexType definition utilizes a sequence the following would be legal : <first>John</first> <middle>Fitzgerald</middle> <last>Doe</last> The following would be illegal : <last>Doe</last> <middle>Fitzgerald</middle> <first>John</first> This example would not be allowable because the elements do not appear in the order that we have specified within our complexType definition.

<choice> The basic structure of our <choice> declaration looks very much like our <sequence> declaration. <choice minOccurs="non negative number" maxOccurs="non negative number or 'unbounded'"> Again, we can specify minOccurs and maxOccurs attributes to modify the cardinality of our <choice> declaration. The <choice> declaration function is also similar to its DTD counterpart. The <choice> declaration allows you to specify multiple declarations. Within an instance document, however, only one of the declarations may be used. For example, suppose we had declared the content model of our <name> element using a <choice> declaration: <element name="name"> <complexType> <choice> <element name="first" type="string"/> <element name="middle" type="string"/> <element name="last" type="string"/> </choice> <attribute name="title" type="string"/> </complexType> </element>

If we had declared our content model as we have in the above example, then within our instance document we could include only the <first> element, only the <middle> element, or only the <last> element. We could not include more than one of the elements within the instance. Just as we saw in our <sequence> declaration, our <choice> declaration may contain <element> declarations, element wildcards, and inner <sequence>, <choice>, or <group> references.

<group> The <group> reference declaration allows us to refer to global element groups within our content model. Don't confuse a <group> reference, which appears within a content model, with a global <group> declaration that defines a reusable group of elements. We have already seen that global element groups function very similarly to global type definitions; they allow us to define content models that can be grouped together and reused within other content models. <group ref="global group definition" minOccurs="non negative number" maxOccurs="non negative number or 'unbounded'"> Within a content model, the <group> is used by creating a reference to an already declared group. This can be done by including a ref attribute and specifying the name of the global <group> declaration. As we saw with element references, the global group reference must be prefixed with the appropriate namespace prefix.

An example could be: <group name="NameGroup"> <sequence> <element name="first" type="string"/> <element name="middle" type="string"/> <element name="last" type="string"/> </sequence> </group> <element name="name"> <complexType> <group ref="target:NameGroup"/> <attribute name="title" type="string"/> </complexType> </element> Here the group reference within our <complexType> definition has a ref attribute with the value target:NameGroup. This refers to the global group declaration named NameGroup. We must prefix the name with a namespace prefix, in this case target, so we can identify the namespace in which the NameGroup declaration appears. Again, we can specify minOccurs and maxOccurs attributes to modify the cardinality of our <group> reference. However, the <group> reference may not contain element children. Of course, as we have already seen, the global <group> declaration which it is referring to will contain element children that define the content model.

<attribute> Within XML Schemas, attribute declarations are similar to element declarations. In the examples for our <name> element, we have already seen an attribute declaration for the title attribute . <attribute . name="name of the attribute" type="global type“ ref="global attribute declaration“ form="qualified or unqualified" use="optional or prohibited or required" default="default value" fixed="fixed value"> As we saw with element declarations, there are three primary methods for declaring attributes: Creating a local type Using a global type Referring to an existing global attribute Unlike elements types, which are divided into simpleTypes and complexTypes, attribute declarations are restricted to simpleTypes. Remember, complexTypes are used to define types that will contain attributes or elements; simpleTypes are used to restrict text only content. Because an attribute can only contain text, we can only use simpleTypes to define their allowable content.

Creating a Local Type Creating a local type for an <attribute> declaration is similar to creating a local type for an <element> declaration. To create a local type, you simply include the type declaration as a child of the <attribute> element: <attribute name="title"> <simpleType>  </simpleType> </element> In this example, we see that an attribute declaration may contain only a <simpleType> definition. We will look at the insides of these declarations a little later. Using a Global Type Just as we saw with our <element> declarations, many of our attributes will have the same type of value. Instead of declaring duplicate local types throughout our schema, we can create a global <simpleType> definition. Within our attribute declarations, we can refer to a global type by name. <attribute name="title" type="string"/> <xs:attribute name="title" type="xs:string"/> In these examples, our attribute declaration refers to a global type named string. This type is a member of the XML Schema vocabulary. When referring to the type we must include the namespace prefix, just as we would for element declarations. The first declaration should look very familiar–we used it in our <name> XML Schemas throughout the beginning of this chapter. It simply declares an attribute, title, which must contain a value of type string.

Datatypes Throughout this chapter, we have seen how to declare elements and attributes using <complexType> definitions. At the start of the chapter, however, we promised that we would see how to define the allowable content for text-only elements and attribute values. It's time that we made good on that promise. The XML Schema Recommendation allows you to use Built-in datatypes User defined datatypes Built-in Datatypes In our examples throughout this chapter, we have used the string type for our text only content. The string type is a primitive data type that allows any textual content. XML Schemas provide a number of simpleTypes that allow you to exercise greater control over textual content in your XML document. The following table lists all of the simpleTypes built into XML Schemas:

An integer whose value is greater than 0 positiveInteger A numeric value representing a whole number integer Hexadecimal encoded binary information hexBinary Base 64 encoded binary information Base64Binary A numeric value from 0 to 255 unsignedByte A numeric value from -128 to 127 Byte A string that does not contain sequences of two or more spaces, tabs, carriage returns or line feed characters token A whitespace normalized string where all spaces, tabs, carriage returns, and line feed characters are converted to single spaces normalizedString Any character data string Description Type

A logical value, including true, false, 0, and 1 Boolean Description Type A numeric value that may or may not include a fractional part decimal A numeric value from 0 to 65535 unsignedShort A numeric value from -32768 to 32767 short A numeric value from 0 to 18446744073709551615 unsignedLong A numeric value from -9223372036854775808 to 9223372036854775807 Long A numeric value from 0 to 4294967295 unsignedInt A numeric value from -2147483648 to 2147483647 Int An integer whose value is less than or equal to 0 nonPositiveInteger An integer whose value is 0 or greater nonNegativeInteger An integer whose value is less than 0 negativeInteger

Description Type A month in the Gregorian Calendar as defined in section 3 of ISO 8601. For example, --07-- is a valid gMonth value gMonth A date according to the Gregorian Calendar as defined in section 5.2.1 of ISO 8601. For example, 1995-05-07 is a valid date value Date A span of time as defined in section 5.5.3.2 of ISO 8601. For example, P30D is a valid duration value indicating a duration of 30 days duration An instant of time including both a date and a time value as defined in section 5.4 of ISO 8601. For example, 1998-07-12:16:30:00.000 is a valid dateTime value dateTime An instant of time that occurs daily as defined in section 5.3 of ISO 8601. For example, 15:45:00.000 is a valid time value. (ISO 8601 can be found at http://www.iso.ch/markete/8601.pdf ) Time A numeric value that corresponds to the IEEE double-precision 64-bit floating point type defined in the standard IEEE 754-1985 double A numeric value that corresponds to the IEEE single-precision 32-bit floating-point type defined in the standard IEEE 754-1985. (IEEE 754-1985 can be found at http://standards.ieee.org/reading/ieee/std_public/description/busarch/754-1985_desc.html ) float

XML DOM The XML Document Object Model (XML DOM) defines a standard way for accessing and manipulating XML documents. The DOM presents an XML document as a tree-structure (a node tree), with the elements, attributes, and text defined as nodes. What is the DOM? "The W3C Document Object Model (DOM) is a platform and language-neutral interface that allows programs and scripts to dynamically access and update the content, structure, and style of a document." The W3C DOM provides a standard set of objects for HTML and XML documents, and a standard interface for accessing and manipulating them. The W3C DOM is separated into different parts (Core, XML, and HTML) and different levels (DOM Level 1/2/3): Core DOM - defines a standard set of objects for any structured document XML DOM - defines a standard set of objects for XML documents HTML DOM - defines a standard set of objects for HTML documents

The DOM Structure Model The DOM treats the XML document as a tree-structure. Each element, attribute, and text in the XML document represents a node in the tree. The terms "parent" and "child" are used to describe the relationships between nodes. Some nodes may have child nodes, while other nodes do not have children (leaf nodes). Because the XML data is structured in a tree form, it can be traversed without knowing the exact structure of the tree and without knowing the type of data contained within. DOM Node Example Look at the following XML file: books.xml XML\ books.doc

Notice that the root element in the XML document above is named <bookstore>. All other elements in the document are contained within <bookstore>. The <bookstore> element represents the root node of the DOM tree. The root node <bookstore> holds four <book> child nodes. The first <book> child node also holds four children: <title>, <author>, <year>, and <price>, which contains one text node each, "Everyday Italian", "Giada De Laurentiis", "2005", and "30.00". IMPORTANT! Text is always stored in text nodes. A common error in DOM processing is to navigate to an element node and expect it to contain the text. However, even the simplest element node has a text node under it. For example, in <year>2005</year>, there is an element node (year), and a text node under it, which contains the text (2005). The following image illustrates a fragment of the DOM node tree from the XML document above:

What is the XML DOM? The XML DOM is the Document Object Model for XML The XML DOM is platform- and language-independent The XML DOM defines a standard set of objects for XML The XML DOM defines a standard way to access XML documents The XML DOM defines a standard way to manipulate XML documents The XML DOM is a W3C standard The DOM views XML documents as a tree-structure. All elements; their containing text and their attributes, can be accessed through the DOM tree. Their contents can be modified or deleted, and new elements can be created. The elements, their text, and their attributes are all known as nodes. DOM Node List This section explains what a NodeList is with examples.

DOM Node List When using properties or methods like childNodes or getElementsByTagName(), we receive a NodeList object. A NodeList object represents an ordered list of nodes. The nodes in the NodeList can be accessed through their index number (starting from 0). Note: In a NodeList, the nodes are returned in the order in which they are specified in the XML. XML\ bookstore.doc

We will now create a node list of all the <title> elements in "books.xml", by using the getElementsByTagName("title")method. The following image represents the node list returned:

The following code fragment gets the text from the first <title> element: getElementsByTagName("title")[0].childNodes[0].nodeValue Output: Everyday Italian Get the Length of a Node List The node list keeps itself up-to-date. If an element is deleted or added, in the node list or the XML document, the list is automatically updated. The node list has a useful property: length. The length property returns the number of nodes in a node list. The following code fragment gets the number of <title> elements in "books.xml": getElementsByTagName('title').length Output: 4

When you know the length of a node list, you can easily loop through it and extract the values you want. The following code fragment loops through all <title> elements and prints their values: XML\print values.doc

Parsing the XML DOM To manipulate an XML document, you need an XML parser. The parser loads the document into your computer's memory. Once the document is loaded, its data can be manipulated using the DOM. The DOM treats the XML document as a tree. There are some differences between Microsoft's XML parser and the XML parser used in Mozilla browsers. In this tutorial we will show you how to create cross browser scripts that will work in both Internet Explorer and Mozilla browsers. Microsoft's XML Parser Microsoft's XML parser is a COM component that comes with Internet Explorer 5 and higher. Once you have installed Internet Explorer, the parser is available to scripts. Microsoft's XML parser supports all the necessary functions to traverse the node tree, access the nodes and their attribute values, insert and delete nodes, and convert the node tree back to XML. To create an instance of Microsoft's XML parser, use the following code: JavaScript: var xmlDoc=new ActiveXObject("Microsoft.XMLDOM");

VBScript: set xmlDoc=CreateObject("Microsoft.XMLDOM") ASP: set xmlDoc=Server.CreateObject("Microsoft.XMLDOM") The following code fragment loads an existing XML document ("note.xml") into Microsoft's XML parser: var xmlDoc=new ActiveXObject("Microsoft.XMLDOM"); xmlDoc.async="false"; xmlDoc.load("note.xml"); The first line of the script above creates an instance of the XML parser. The second line turns off asynchronized loading, to make sure that the parser will not continue execution of the script before the document is fully loaded. The third line tells the parser to load an XML document called "note.xml".

XML Parser in Mozilla, Firefox, and Opera Mozilla's XML parser supports all the necessary functions to traverse the node tree, access the nodes and their attribute values, insert and delete nodes, and convert the node tree back to XML. To create an instance of the XML parser in Mozilla browsers, use the following code: JavaScript: var xmlDoc=document.implementation.createDocument(" ns "," root ",null); The first parameter, ns , defines the namespace used for the XML document. The second parameter, root , is the XML root element in the XML file. The third parameter, null, is always null because it is not implemented yet. The following code fragment loads an existing XML document ("note.xml") into Mozillas' XML parser: var xmlDoc=document.implementation.createDocument("","",null); xmlDoc.load("note.xml"); The first line of the script above creates an instance of the XML parser. The second line tells the parser to load an XML document called "note.xml".

Parsing an XML File - A Cross browser Example The following example is a cross browser example that loads an existing XML document ("note.xml") into the XML parser: XML\ parsing_xml.doc Important Note To extract the text (Jani) from an XML element like: <from>Jani</from>, the correct syntax is: getElementsByTagName("from")[0].childNodes[0].nodeValue IMPORTANT: getElementsByTagName returns an array of nodes. The array contains all elements with the specified name within the XML document. In this case there is only one "from" element, but you still have to specify the array index ( [0] ).

Traversing the Node-tree Often you will need to loop through elements in an XML document or string. The example below loops through all child nodes of <note>, and prints the node name and the node value of each node: XML\node tree.doc

Get an Element's Value The getElementsByTagname() method returns a nodelist that contains all elements with the specified tag name in the same order as they appear in the source document. The following code fragment prints the values of all "title" elements in "books.xml": XML\element value.doc

Get an Attribute's Value The getAttribute() method can be used to display the value of an attribute. The following code fragment prints the values of all "category" attributes in "books.xml": XML\attribute value.doc

Get an Item's Value The getNamedItem() method can be used to retrieve a specified node. The following code fragment shows how to print the value of the "category" attribute in each <book> element": XML\item value.doc

Set a New Attribute and Attribute Value The setAttribute() method can be used to change the value of an existing attribute, or to create a new attribute/attribute value for an element. The following code fragment adds a new attribute/attribute value to each <book> element: xmlDoc=loadXMLDoc("books.xml"); var x=xmlDoc.getElementsByTagName("book"); for(i=0;i<x.length;i++) { x.item(i).setAttribute("edition","first"); }

Another Way to Create a New Attribute The createAttribute() is used to create a new attribute node. The following code fragment uses createAttribute() to create a new attribute node, and setAttributeNode() to insert it to an element.: xmlDoc=loadXMLDoc("books.xml"); var x=xmlDoc.getElementsByTagName('book'); var newatt; for (i=0;i<x.length;i++) { newatt=xmlDoc.createAttribute("edition").value="first"; x[i].setAttributeNode(newatt); }

Change an Attribute Value The setAttribute() method can be used to change the value of an existing attribute, or to create a new attribute/attribute value for an element. The following code fragment changes the value of the existing "category" attribute (in each <book> element): xmlDoc=loadXMLDoc("books.xml"); var x=xmlDoc.getElementsByTagName("book"); for(i=0;i<x.length;i++) { x.item(i).setAttribute("category","bestseller"); }

Change an Item's Value The getNamedItem() method can be used to change the value of an existing item. The following code fragment also changes the value of the existing "category" attribute (in each <book> element): xmlDoc=loadXMLDoc("books.xml"); var x=xmlDoc.getElementsByTagName("book"); for(i=0;i<x.length;i++) { var att=x.item(i).attributes.getNamedItem("category") att.value="bestseller"; } To manipulate an XML document, you need an XML parser. The parser loads the document into your computer's memory and allows you to manipulate it using the DOM. There are some differences between Microsoft's XML parser and the XML parser used in Mozilla browsers. The loadXMLDoc function is a cross browser script that will allow parsing in both Internet Explorer and Mozilla browsers. The following JavaScript function is stored in the "loadxmldoc.js" file and loaded in the <head> of the examples: XML \change item.doc

Loading the File and Returning the XML Document After the right parser is created the following code is run: xmlDoc.async=false; xmlDoc.load(dname); return(xmlDoc); The first line turns off asynchronized loading, so that the parser will not continue execution of the script before the document is fully loaded The second line tells the parser to load an XML document The third line returns the XML Document Remove an Element The removeChild() method can be used to remove a specified node. The following code fragment will remove the last <book> element from the loaded xml:

//check if last child node is an element node function get_lastchild(n) { var x=n.lastChild; while (x.nodeType!=1) { x=x.previousSibling; } return x; } xmlDoc=loadXMLDoc("books.xml") ;var x=xmlDoc.documentElement; x.removeChild(get_lastchild(x)); Note: Internet Explorer will skip white-space text nodes that are generated between nodes (e.g. new-line characters), while Mozilla will not. So, in the example above, the get_lastchild() function checks the node type of the last child node of the parameter.

Element nodes has a nodeType of 1, so if not the last child of the node in the parameter is an element node, it moves to the previous node, and checks if this node is an element node. This continues until the last child node (which must be an element node) is found. This way, the result will be correct in both Internet Explorer and Mozilla. ] Remove Text From an Element The deleteData() method is used to remove data from a text node. The deleteData() method has two parameters: offset - Where to begin removing characters. Offset value starts at zero count - How many characters to delete The following code fragment will remove the first nine characters from the first <title> element in the loaded XML: xmlDoc=loadXMLDoc("books.xml"); var x=xmlDoc.getElementsByTagName("title")[0].childNodes[0]; x.deleteData(0,9 );

Remove an Attribute The removeAttribute() method is used to remove an attribute node. The following code fragment will remove all "category" attributes in each <book> element: xmlDoc=loadXMLDoc("books.xml"); var x=xmlDoc.getElementsByTagName('book'); for(i=0;i<x.length;i++) { x.item(i).removeAttribute('category'); } removeAttributeNode() The removeAttributeNode() method is used to remove an attribute node. The following code fragment will remove all "category" attributes in each <book> element: XML\remove attribute.doc

Replace a Node in a Node List The replaceChild() method is used to replace a node in a node list. The following code fragment creates a new <book> element that will replace the last <book> element: XML\replace node.doc Note: Internet Explorer will skip white-space text nodes that are generated between nodes (e.g. new-line characters), while Mozilla will not. So, in the example above, the get_lastchild() function checks the node type of the last child node of the parameter. Element nodes has a nodeType of 1, so if not the last child of the node in the parameter is an element node, it moves to the previous node, and checks if this node is an element node. This continues until the last child node (which must be an element node) is found. This way, the result will be correct in both Internet Explorer and Mozilla.

Create an Element The createElement() method creates a new element node. The following code fragment creates an element (<edition>), and adds it after the last child of each <book> element: xmlDoc=loadXMLDoc("books.xml"); var x=xmlDoc.getElementsByTagName('book'); var newel for (i=0;i<x.length;i++) { newel=xmlDoc.createElement('edition'); x[i].appendChild(newel); }

Create an Attribute The createAttribute() creates a new attribute node. The following code fragment creates an "edition" attribute and adds it to all <book> elements: xmlDoc=loadXMLDoc("books.xml"); var x=xmlDoc.getElementsByTagName('book'); var newatt; for (i=0;i<x.length;i++) { newatt=xmlDoc.createAttribute("edition"); newatt.value="first"; x[i].setAttributeNode(newatt); }

Create a Text Node The createTextNode() method creates a new text node.The following code fragment creates an element (<edition>), with a text node ('First') in it, and adds it after the last child of each <book> element: xmlDoc=loadXMLDoc("books.xml"); var x=xmlDoc.getElementsByTagName('book'); var newel,newtext for (i=0;i<x.length;i++) { newel=xmlDoc.createElement('edition'); newtext=xmlDoc.createTextNode('First'); newel.appendChild(newtext); x[i].appendChild(newel); }

Create a CDATA Section Node The createCDATASection() method creates a new CDATA section node. The following code fragment creates a CDATA section, and adds it after the last child of each <book> element: xmlDoc=loadXMLDoc("books.xml"); var x=xmlDoc.getElementsByTagName('book'); var newCDATA,newtext; newtext="Special Offer & Book Sale"; for (i=0;i<x.length;i++) { newCDATA=xmlDoc.createCDATASection(newtext); x[i].appendChild(newCDATA); }

Create a Comment Node The createComment() method creates a new comment node. The following code fragment creates a comment node, and adds it after the last child of each <book> element: xmlDoc=loadXMLDoc("books.xml"); var x=xmlDoc.getElementsByTagName('book'); var newComment,newtext; newtext="Revised September 2006"; for (i=0;i<x.length;i++) { newComment=xmlDoc.createComment(newtext); x[i].appendChild(newComment); }

Add a Node to The End of a Node List The appendChild() method is used to add a node after the last child of a specific node. This method is useful when the position of the added node is not important. The following code fragment creates an element (<edition>), and adds it after the last child of each <book> element: xmlDoc=loadXMLDoc("books.xml"); var x=xmlDoc.getElementsByTagName('book'); var newel,newtext for (i=0;i<x.length;i++) { newel=xmlDoc.createElement('edition'); newtext=xmlDoc.createTextNode('First'); newel.appendChild(newtext); x[i].appendChild(newel); }

Insert a Node Before a Specific Node The insertBefore() method is used to insert a node before a specific node. This method is useful when the position of the added node is important. The following code fragment creates a new <book> element and inserts it before the last <book> element: XML\specific node.doc Note: Internet Explorer will skip white-space text nodes that are generated between nodes (e.g. new-line characters), while Mozilla will not. So, in the example above, the get_lastchild() function checks the node type of the last child node of the parameter. Element nodes has a nodeType of 1, so if not the last child of the node in the parameter is an element node, it moves to the previous node, and checks if this node is an element node. This continues until the last child node (which must be an element node) is found. This way, the result will be correct in both Internet Explorer and Mozilla.

Set a New Attribute and Attribute Value The setAttribute() method can be used to change the value of an existing attribute, or to create a new attribute/attribute value for an element. The following code fragment adds a new attribute/attribute value to each <book> element: xmlDoc=loadXMLDoc("books.xml"); var x=xmlDoc.getElementsByTagName("book"); for(i=0;i<x.length;i++) { x.item(i).setAttribute("edition","FIRST"); } Note: If the "edition" attribute already exists, the setAttribute() method will overwrite the attribute's value.

What is XSL? Extensible Stylesheet Language , as the name implies, is an XML-based language used to create stylesheets . An XSL engine uses these stylesheets to transform XML documents into other document types, and to format the output. In these stylesheets you define the layout of the output document, and where to get the data from within the input document. That is, "retrieve data from this place in the input document; make it look like this in the output". In XSL parlance, the input document is called the source tree , and the output document the result tree . It is important to remember that, because XSL is an XML-based language, every XSL stylesheet must be a well-formed XML document. Why is XSLT So Important for e-Commerce? To get an idea of the power of XSLT, let's create a fictional example to demonstrate. Imagine that there are two companies working together, sharing information over the Internet. Mom And Pop is a store, which sends purchase orders to Frank's Distribution , which fulfills those orders. Let's assume that we have already decided that XML is the best way to send that information.

Unfortunately, the chances are that Mom And Pop will need a different set of information for this transaction from Frank's Distribution . Perhaps Mom And Pop needs information on the salesperson that made the order for commissioning purposes, but Frank's Distribution doesn't need it. On the other hand, Frank's Distribution needs to know the part numbers, which Mom And Pop doesn't really care about. Mom And Pop uses XML such as the following: <?xml version="1.0"?> <order> <salesperson>John Doe</salesperson> <item>Production-Class Widget</item> <quantity>16</quantity> <date> <month>1</month> <day>13</day> <year>2000</year> </date> <customer>Sally Finkelstein</customer> </order>

Whereas Frank's Distribution requires XML that looks more like this: <?xml version="1.0"?> <order> <date>2000/1/13</date> <customer>Company A</customer> <item> <part-number>E16-25A</part-number> <description>Production-Class Widget</description> <quantity>16</quantity> </item> </order> In this scenario, we have three choices: Mom And Pop can use the same structure for its XML that Frank's Distribution uses. The disadvantage is that it now needs a separate XML document to accompany the first one, for its own additional information. However, the business-to-business (B2B) communication is much easier, since both companies are using the same format. Frank's Distribution can use the same format for its XML that Mom And Pop uses. This would have the same results as the previous choice.

Both companies can use whatever XML format they wish internally, but transform their data to a common format whenever they need to transmit the information outside. Obviously this option provides the most flexibility for both companies, and still allows cross-company communication. For the last option, both companies would probably agree on this common format in advance. Then, whenever Mom and Pop wanted to send information to Frank's Distribution , it would first transform it XML to this common format, and then send it. Similarly, whenever Frank's Distribution wanted to send information to Mom and Pop , it would first transform its internal XML documents to this common format, and then send it. In this way, any time either company receives information from the other, it will be in a common format. With XSLT, this kind of transformation is quite easy: it's probably one of the most important uses of XSLT, and one of the more exciting areas where XML is already making its presence felt.

How XSLT Stylesheets Work-Templates As mentioned earlier, XSLT stylesheets are XML documents. XSLT processors act on any XML elements that are in the XSLT namespace (which is http://www.w3.org/1999/XSL/Transform ), and any other elements in the document, regardless of their namespace, are added to the result-tree as-is. XSLT stylesheets are built on structures called templates . A template specifies what to look for in the source tree, and what to put into the result tree. For example: <xsl:template match="quantity">quantity tag found!</xsl:template> Templates are defined using the XSLT <xsl:template> element. There are two important pieces to this template: the match attribute, and the contents of the template. The match attribute specifies a pattern in the source tree; this template will be applied for any nodes in the source tree that match that pattern. In this case, the template will be applied for any elements named "quantity".

Everything inside the template, between the start- and end-tags, is what will be output to the result tree. Any elements in the XSLT namespace are special XSLT elements, which indicate to the processor that it should do some work, while any other elements or text which appear inside the <xsl:template> element will end up in the output document as-is. The contents of a template can be-and almost always are-much more complex than simply outputting text. There are numerous XSLT elements you can insert into the template to perform various actions. For example, there's an <xsl:value-of> element, which can take information from the source tree, and add it to the result tree. The following will work the same as our previous template, but instead of outputting "quantity tag found!" this template will add the contents of any elements named "quantity" to the result tree: <xsl:template match="quantity"> <xsl:value-of select="."/> </xsl:template> In other words, if the XSLT engine finds: <first>John</first> it will output John, and if it finds:<first>Andrea</first> it will output Andrea.

Associating Stylesheets with XML Documents Using Processing Instructions In many, if not most, cases XSLT transformations will be performed by passing an XML document and an XSLT stylesheet to an XSLT processor. However, an XSL stylesheet can also be associated with an XML document using a processing instruction like this: <?xml-stylesheet type="text/xsl" href="stylesheet.xsl"?> In this case, when a browser that understands XML and XSLT loads the XML document, it will automatically do the XSLT transformation for us, and display the results. Before we go on to study XSLT in depth, we should stop here and discuss the type of programming you'll be doing with XSLT. There are two classifications of programming languages in the computing world: imperative and declarative .

Imperative Programming Imperative programming languages are ones like JavaScript, Java, or C++, where the programmer tells the computer exactly what to do, and how to do it. Declarative Programming XSLT is not an imperative programming language like JavaScript, it's declarative , and declarative languages don't require quite so much work from the developer. With XSLT, we don't specify to the computer how we want anything done, just what we want it to do. We do this using templates, which specify the conditions in which the process takes place and the output that's produced. How to do the work is entirely up to the processor. For example, assuming that our three strings were in an XML file like so (paras.xml): <?xml version="1.0"?> <strings> <s>Para 1</s> <s>Para 2</s> <s>Para 3</s> </strings>

We could get the same HTML as above using an XSLT stylesheet like this (paras.xsl): <?xml version="1.0"?> <xsl:stylesheet version="1.0„ xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:output method="html" indent="yes" encoding="UTF-8"/> <xsl:template match="/"> <html> <body> <xsl:for-each select="strings/s"> <xsl:value-of select="."/> </xsl:for-each> </body> </html> </xsl:template> </xsl:stylesheet> If you try this out in MSXSL, you'll see that we get the same results:

> msxsl paras.xml paras.xsl <html> <body> Para 1 Para 2 Para 3 </body> </html> Notice that this stylesheet looks very much like the output, with some XSLT elements mixed in to specify where content should go–these are the elements in the http://www.w3.org/1999/XSL/Transform namespace. The XSLT engine will: Find the document root of the source tree. (That is, the virtual root of the document's hierarchy–more on the document root coming up.) Match the document root against the single template in our stylesheet. Output the HTML elements in the template. Process the XSLT elements in the template. The <xsl:for-each> works like a template-in-a-template, and applies to any <s> elements which are children of a <strings> root element. The contents of this template are a element, which will be output to the result tree, and the <xsl:value-of> element. The <xsl:value-of> element will output the contents of those <s> elements to the result tree, as the contents of the element.

If we wanted to, we could even specify the order in which we want our paragraphs sorted, by simply changing the <xsl:for-each> element from this: <xsl:for-each select="strings/s">  </xsl:for-each> to this: <xsl:for-each select="/strings/s"> <xsl:sort select="."/>  </xsl:for-each> which tells the XSLT engine to sort the results, and tells it what data to sort by. (In this case, the results are sorted alphabetically by the contents of the <s> element.

XPath Even in the short examples we've seen so far in this chapter, it seems like we're spending a lot of time looking at pieces of the source tree; we must need a pretty flexible way of pointing to different pieces of an XML document. In fact, there's a whole separate specification from the W3C for a language called XPath , which does exactly that: address sections of an XML document, to allow us to get the exact pieces of information we need. XSL uses XPath extensively. XPath version 1.0 became a W3C recommendation on 16 Nov 1999, and can be found at http://www.w3.org/TR/xpath. XPath is not only used in XSLT, it is also used in other W3C technologies, such as XPointer . You use XPath expressions to address your documents by specifying a location path , which conveys to XPath, step-by-step, where you are going in the document. Of course, you can't know where you're going unless you know where you are, so XPath also needs to know the context node; that is, the section of the XML document from which you're starting.

A node is simply a "piece" of an XML document; it could be an element, an attribute, a piece of text, or any other part of an XML document. XPath adds the concept of a node because it's often useful to work with the parent/child relationships of an XML document without having to worry about whether the branches and leaves are elements, attributes, pieces of text, or anything else. XPath also introduces the concept of a node-set , which is simply a collection (or "set") of nodes. In order to illustrate the XPath examples below we'll use a sample XML document, which you might want to save the following to your hard drive as order.xml, and keep it handy: <?xml version="1.0"?> <order OrderNumber="312597"> <date>2000/1/13</date> <customer id="A216">Company A</customer> <item> <part-number warehouse="Warehouse 11">E16-25A</part-number> <description>Production-Class Widget</description> <quantity>16</quantity> </item> </order> We've just added some attributes, for the sake of demonstrating how to address them with XPath.

How Do Templates Affect the Context Node? An important point to remember in XSLT is that whatever the template uses for its match attribute becomes the context node for that template. This means that all XPath expressions within the template are relative to that node. Take the following example: <xsl:template match="/order/item"> <xsl:value-of select="part-number"/> </xsl:template> This template will be instantiated for any <item> element that is a child of an <order> element that is a child of the document root. That <item> element is now the context node for this template, meaning that the XPath expression in the <xsl:value-of> attribute is actually only selecting the <part-number> element which is a child of the <item> element already selected for this template.

XPath Basics As mentioned earlier, XPath expressions give directions through an XML document, from one point in the document to another. These directions are given step-by-step, starting at the context node, where each step is separated by a "/" character. Consider the following: order/item This expression gives the following directions: Start at the context node (this direction is implicit–it is not actually stated in the expression) Go to the first child element which is named "order" Finally, select the first child element of the <order> element which is named "item" Each step in the XPath expression specifies an XML element, in this case an <order> element and an <item> element. Alternatively, attributes can be specified in XPath expressions, by putting a "@" character in front of the name of the attribute. For example, order/@OrderNumber is the same as the previous expression, except that instead of selecting an <item> child element of the <order> element, it is selecting an OrderNumber attribute of the <order> element.

XPath expressions are used for XSLT elements such as <xsl:value-of>, which is used to pull information out of the source tree, such as the following: < xsl:value-of select="order/item"/> which would insert the value of the <item> element into the result tree. In addition to XPath expressions, there are also XPath patterns . In an XPath pattern, instead of giving directions to a particular node, you are specifying a type of node against which to match. Patterns are used in templates, to indicate to the processor when the template should be instantiated. Consider the following: <xsl:template match="order/item"> This template will match any <item> element in the source tree which is a child of an <order> element.

The Document Root An important thing to note about XPath is the concept of the document root , which is not the root element we learned. Since there can be other things at the beginning or end of an XML document before or after the root element, XPath needs a virtual document root to act as the root of the document's hierarchy. In fact, the root element is a child of the document root. The document root doesn't point at any element in the document; it's just the conceptual root of the document. In XPath, the document root is specified by a single "/". This is why the template in our first XSLT example, which matched against "/", applied to the entire document. <xsl:template match="/"> The "/" character also refers to the document root when it is at the beginning of an XPath expression or pattern. For example,

<xsl:value-of select="/name/first"/> tells the XSLT processor to go to the document root, then to the <name> root element, and finally to the first child of that <name> element named "first", and get the value of it. This will always refer to the same element, regardless of what the context node might be, because it starts right from the document root and goes from there. XPath expressions and patterns can be relative , meaning that they start at the context node, or absolute , meaning that they start at the document root. The document root is especially important in XSLT stylesheets, since this is where all processing starts. The XSLT processor looks through the stylesheet for a template that matches the document root, and from this point on, all processing is controlled by the contents of this template.

Filtering XPath Expressions and Patterns So now that we can address pieces of our XML document, can we get more specific? Of course! Not only can we locate nodes which are in specific locations in our document, but we can match against nodes with specific values, or that meet other conditions. So, for example, instead of matching against <first> elements from the source tree, we could match only <first> elements whose text is "John". This is done using "[]" brackets, which act like a filter (also called a predicate ) on the node being selected. We can test for elements with specific child nodes by simply putting the name of the child node in the "[]" brackets. So: "order[customer]" matches any <order> element which is a child of the context node and which has a <customer> child element. "order[@number]" matches any <order> element which is a child of the context node and which has a number attribute. And to take it a step further, "order[customer = 'Company A']" matches any <order> element which is a child of the context node, and which has a <customer> child with a value of "Company A".

Notice that in all of the cases previous we're selecting the <order> element, not the number attribute or the <customer> element. The "[]" brackets just act as a filter, so that only certain <order> elements will be selected. To check for a node with a specific value, you would use "." for the comparison. (In XPath, "." refers to the context node.) For example, "customer[. = 'Company A']" matches any <customer> element with a value of "Company A". These filters can be as complex as we want. For example, "order[customer/@id = '216A']" says select any <order> elements which have a child element named <customer>, which in turn has an id attribute with a value of "216A". But again, it's still the <order> element we're selecting, not the <customer> element or the id attribute.

Dealing with Complex Expressions For more complex XPath expressions, like the following: /order[@number = '312597']/item/part-number[@warehouse = 'Warehouse 11'] you might find it easier to break things down into steps. For example, you can specify the XPath expression to the node you want to select, and then add in any filters after. In this case, we can first write the XPath expression as: /order/item/part-number We can then narrow this down to only select the <part-number> elements whose warehouse attribute has a value of "Warehouse 11": /order/item/part-number [@warehouse = 'Warehouse 11'] And finally, we select these <part-number> elements only if they are descended from an <order> element whose number attribute had the value "312597": /order [@number = '312597'] /item/part-number[@warehouse = 'Warehouse 11']

XPath Functions In order to make XPath even more powerful and useful, there are a number of functions that can be used in XPath expressions. Some of these can be used to return nodes and node-sets that can't be matched with regular parent/child and element/attribute relationships. There are also functions that can be used to work with strings and numbers, which can be used both to retrieve information from the original document, and to format it for output. You can recognize functions because they end with "()" parentheses. Some functions need information to work; this information is passed in the form of parameters , which are inserted between the "()" parentheses. For example, there is a function called string-length(), which returns the number of characters in a string. It might be used something like this:

string-length('this is a string') The parameter is the string "this is a string". The function string-length()will use this information to calculate its result (which, in this example, is 16, since there are 16 characters in that string). Some functions will take parameters, but will also have default parameters . In these cases, you can use the function without passing it any parameters, but the function will operate as if you had passed it the default parameters. For example, the string-length() function defaults to the context node if no parameters are passed. So simply saying: string-length() is the same as saying string-length(.) where the period, ".", represents the context node.

<xsl:stylesheet> The <xsl:stylesheet> element is the root element of nearly all XSLT stylesheets, and is used like this: <xsl:stylesheet version="version number" xmlns:xsl= http://www.w3.org/1999/XSL/Transform exclude-result-prefixes="space-separated list of NS prefixes"> If you are following the current (at the time of writing) XSLT specification from the W3C, you should use "1.0" for the version number. Remember also that all of the XSLT elements are in the XSLT namespace, which is almost always declared on the <xsl:stylesheet> element, since it's the root element for the document. As mentioned before, we'll use the convention of using "xsl" as our namespace prefix, although you can use whatever prefix you wish. (Some people simply use "x" for their XSLT namespace prefix, to save on typing.) Instead of the <xsl:stylesheet> element, you could use the <xsl:transform> element. It has exactly the same meaning and syntax as <xsl:stylesheet>, and is available for those who wish to differentiate their XSLT stylesheets from their XSL Formatting Objects stylesheets. Most people don't use it, however, and stick to <xsl:stylesheet> exclusively, which is the practice we'll follow.

For stylesheets which will only define one template, which matches against the document root, the <xsl:stylesheet> element is optional. For example, instead of this stylesheet from earlier: <?xml version="1.0"?> <xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <xsl:template match="/"> <html> <body> <xsl:for-each select="strings/s"> <xsl:value-of select="."/> </xsl:for-each> </body> </html> </xsl:template> </xsl:stylesheet>

we could have used this instead: <html xsl:version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform"> <body> <xsl:for-each select="strings/s"> <xsl:value-of select="."/> </xsl:for-each> </body> </html> Both of these stylesheets mean exactly the same thing to an XSL processor. All you need to specify are the xsl:version global attribute and the XSLT namespace prefix, and include the rest of the XSLT elements you need as usual.

<xsl:template> As we have seen already, <xsl:template> is the element used to define the templates which make up our XSLT stylesheets. Although this is one of the more important elements you'll be using with XSLT, it's also one of the simplest: <xsl:template match="XPath pattern" name="template name" priority="number" mode="mode name"> The match attribute is used to specify the XPath pattern which is matched against the source tree. The name attribute can be used to create a named template; that is, a template which you can explicitly call in your stylesheet. Named templates will be discussed in a section of their own, later in the chapter. The mode attribute can be used when the same section of the source tree must be processed more than once.

<xsl:apply-templates> The <xsl:apply-templates> element is used from within a template, to call other templates: <xsl:apply-templates select="XPath expression" mode="mode name"> For example, consider the following: <xsl:template match="order"> <requisition> <xsl:apply-templates> </requisition> <xsl:apply-templates/> </xsl:template> This template matches <order> elements, so any time the XSLT engine comes across one in the source tree, this template will be instantiated. When it is, a <requisition> element will be inserted into the result tree. However, we also have an <xsl:apply-templates> element in here, meaning that the XSLT engine will then look for any children of the <order> element, in the source tree, which can be matched against other templates. If there are any other such templates, the content that they add to the result tree will be inserted within the <requisition> element's start and end tags.

If the select attribute is specified, then the XPath expression specified will be evaluated, and the result will be used as the context node which other templates are then checked against. It is optional, though, so if it's not specified then the current context node will be used instead. For example, consider the following modification of our previous template: <xsl:template match="order"> <requisition> <xsl:apply-templates select="item"> <xsl:apply-templates select="item"/> </requisition> </xsl:template> In this case, the XSLT engine will only look for templates that match the <item> child of the <order> element. Even if <order> has other children, the XSLT engine will not try to match them against templates, so they won't get processed.

Try It Out-Our First Stylesheet We now have enough XSLT elements to create a rudimentary stylesheet. For this example, we will create an XML document containing a list of names. Our stylesheet will create a simple HTML document, and for each <name> encountered, it will output a paragraph with the text "name encountered". This isn't really the type of processing you would probably do in the real world, but it will prepare us for some more complex transformations later in the chapter, and give us a chance to use the XSLT elements we have come across so far. First stylesheet.doc

How It Works After the XSL processor has loaded the XML document and the XSLT stylesheet, it instantiates the template which matches the document root. This template outputs the <html>, <head>, <body>, and <title> elements, and then comes across the <xsl:apply-templates>. It then searches the source tree for further nodes that can be matched against templates, and for each <name> element instantiates the second template. The second template simply outputs "Name encountered".

Getting Information from the Source Tree with <xsl:value-of> Okay, so the last stylesheet was kind of boring. Now that we've got the basics for creating XSLT stylesheets, it would be great if we could actually get them to do something useful with the information in our source tree. The <xsl:value-of> element is the way to accomplish this: <xsl:value-of select="XPath expression" disable-output-escaping="yes or no"/> The element is simple. It searches the context node for the value specified in the select attribute's XPath expression, and inserts it into the result tree. For example: <xsl:value-of select="customer/@id"> inserts the text from the id attribute of the <customer> element, and <xsl:value-of select="."> inserts the PCDATA from the context node into the output. (Remember, in XPath "." is a shorthand for the context node.)

The disable-output-escaping attribute causes the XSLT processor to output "&" and "<" characters, instead of "&" and "<" escape sequences. Normally, the XSLT processor automatically escapes these characters for you if they make it into the output, but if you specify disable-output-escaping as "yes", then they won't. (The default is "no".) For example, if we have the following XML element in the input file: <name>&</name> we have two options. This: <xsl:value-of select="name" disable-output-escaping="no"/> which produces: & and this: <xsl:value-of select="name" disable-output-escaping="yes"/> which produces: & Of course, you need to keep in mind that your output will not be well-formed XML if you do this. Therefore, you should only use disable-output-escaping if your output is in some format other than XML (such as HTML or plain text), or if you just have no other alternative. (For example, if you need your output to contain "&", you might put "&amp;" into your stylesheet, with disable-output-escaping set to "yes". Then the XSLT engine will process the first "&" and insert "&" into the stylesheet, which will then be followed by the second "amp;". However, this is a rare situation, so you won't often need to resort to tricks like this.)

Try It Out–<xsl:value-of> in Action Now that we can access the information in our source tree, let's make better use of our list of names. We'll modify the stylesheet from the last Try It Out, so that in the second template each paragraph will contain the text from the <name> elements, instead of a simple string. XSL value in action.doc

Creating the Output So far we've seen how we can create our result tree by inserting elements and other markup into the stylesheet; anything that isn't in the XSLT namespace will be inserted as-is. However, sometimes we might need more flexibility than inserting hard-coded markup into the stylesheet. We will sometimes also need a way to tell the XSLT processor what kind of output to create-XML, HTML, or plain text. This section will include some XSLT elements we can use to do these things. <xsl:output> We've mentioned that XSLT can output XML, or HTML, or even plain text. The <xsl:output> element allows us to specify the method we'll be using, and also gives us much more control over the way our output is created. If it is included in a stylesheet, it must be a direct child of the <xsl:stylesheet> element. In XSLT, elements which must be direct children of <xsl:stylesheet> are called top-level elements. The syntax of <xsl:output>, with some of its most commonly used attributes, is as follows: (we are talking abt xpath.xml) xsl output.doc

The method attribute specifies which type of output is being produced: "xml"-the output will be well-formed XML. "html"-the output will be HTML, and will follow the rules outlined in the W3C's HTML Recommendation "text"-the output will be plain text Some other method. The XSLT specification says that XSLT processors are free to define other types for the method attribute, which they can use for other output methods. If so, the value of the method attribute must be a QName, so that the XSLT processor can use its namespace prefix to identify this method. If the <xsl:output> element is not included, and the root element in the result tree is <html> (in uppercase or lowercase), then the default output method is "html"; otherwise, the default output method is "xml". When the method attribute is specified as "html", the XSL processor can do things like changing " " in the stylesheet to " " in the result tree, since HTML browsers expect the tag to be written like that. (Of course, if you wished to produce XHTML, you would probably set the method attribute to "xml", to ensure that the XSLT engine would produce well-formed XML. There isn't an "xhtml" value for the method attribute.)

<xsl:element> We've already seen how to insert elements directly into the result tree, but what if we don't know ahead of time what elements we're creating? That is, what if the names of the elements that go into the result tree depend on the contents of the source tree? The <xsl:element> element allows us to dynamically create elements: <xsl:element name="element name" use-attribute-sets="attribute set names“ namespace="namespace URI"> The name attribute specifies the name of the element. So the following: <xsl:element name="blah">My text</xsl:element> will produce an element like this in the result tree: <blah>My text</blah> Of course, this isn't very exciting, or dynamic. We could have done the same thing by simply writing that <blah> element into the stylesheet manually, and with less typing. The exciting and dynamic part comes into play when we change the name attribute like so: <xsl:element name="{.}">My text</xsl:element>

Anything inserted into those curly braces gets evaluated as an XPath expression! In this case, we will create an element, and give it the name from the value from the context node. That is, if we have a template like this: <xsl:template match="name"> <xsl:element name="{.}">My text</xsl:element> </xsl:template> then running it against: <name>Andrea</name> will produce: <Andrea>My text</Andrea> and running it against: <name>Ify</name> will produce: <Ify>My text</Ify> The namespace attribute specifies what namespace, if any, this element belongs to.

Like the name attribute, you can include curly braces, and have the namespace calculated at run-time from an XPath expression. For example, if your source tree included an element like this: <some-element>http://www.sernaferna.com/namespace</some-element> you could create an element like so: <xsl:element name="ns-elem" namespace="{.}">...</xsl:element> which would produce an element like this: <ns-elem xmlns="http://www.sernaferna.com/namespace">...</ns-elem> Or, if you wish to use a namespace prefix, you can use a QName for the name attribute, and whatever prefix you specify will be used for the namespace prefix in the output. For example, <xsl:element name="x:ns-elem" namespace="{.}">...</xsl:element> would produce this: <x:ns-elem xmlns:x="http://www.sernaferna.com/namespace">...</x:ns-elem>

Try It Out-<xsl:element> in Action To demonstrate <xsl:element>, let's take an XML document which uses attributes exclusively for its information, and transform it to one which uses elements instead. XSL element in action.doc

<xsl:attribute> and <xsl:attribute-set> Similarly to <xsl:element>, <xsl:attribute> can be used to dynamically add an attribute to an element in the result tree: <xsl:attribute name="attribute name" namespace="namespace URI"> It works in exactly the same way, with the name attribute specifying the name of the attribute, the namespace attribute specifying the namespace URI (if any), and the text inside the <xsl:attribute> element specifying its value. For example: <name><xsl:attribute name="id">213</xsl:attribute>Chaulene</name > will produce the following in the result tree: <name id="213">Chaulene</name> and: <name><xsl:attribute name="{.}">213</xsl:attribute>Chaulene</name >

will do the same, but the name of the attribute will be the text of the context node. Be careful, though! The name of the attribute still has to be a valid XML attribute name! So if the value of the context node above were "Fitzgerald Johansen", you would be attempting to create an attribute name with a space in it, which the XSLT Processor would reject. Note that <xsl:attribute> must come before any PCDATA of the element to which it is being appended. So if we rewrote the above XSLT like this: <name>Chaulene<xsl:attribute name="{.}">213</xsl:attribute></name> the attribute wouldn't get appended to the <name> element. (MSXSL simply ignores the attribute in this case. Other processors may treat the error differently.)

Related Groups of Attributes An <xsl:attribute-set> is a handy shortcut for a related group of attributes that always go together: <xsl:attribute-set name="name of att set“ use-attribute-sets="att set names"> For example, if we have an id attribute and a size attribute, we can define an attribute set as follows: <xsl:attribute-set name="IdSize"> <xsl:attribute name="id">A-213</xsl:attribute> <xsl:attribute name="size">123</xsl:attribute> </xsl:attribute-set> which will append an id with a value of "A-213" and a size with a value of "123" to any element which uses this attribute set. For example, <xsl:element name="order" use-attribute-sets="IdSize"/> would produce this output <order id="A-213" size="123"/>

Or we can define the attribute set like this: <xsl:attribute-set name="IdSize"> <xsl:attribute name="{.}">A-123</xsl:attribute> <xsl:attribute name="size"><xsl:value-of select="."/></xsl:attribute> </xsl:attribute-set> which will append one attribute with the same name as the text of the context node, and a value of "123", and another value with the name size, and the value of the text of the context node. This attribute set can then be appended to elements in the result tree by using the use-attribute-sets attribute of <xsl:element>. Notice also that attribute sets can use other attribute sets, since <xsl:attribute-set> also has a use-attribute-sets attribute!

Controlling the Flow of Stylesheets As you are creating your stylesheets, you may sometimes need to decide at run-time how the results should be created. This section will introduce some XSLT elements that you can use to control the flow of processing within your stylesheets. Conditional Processing with <xsl:if> and <xsl:choose> Every programming language in the world has to let you make choices in your code, otherwise it wouldn't be very useful. XSLT is no exception, and it allows us a couple of ways to make choices: <xsl:if> and <xsl:choose>: <xsl:if test="Boolean expression"> <xsl:choose>. <xsl:when test="Boolean expression"> <xsl:when test="Boolean expression"> <xsl:otherwise> </xsl:choose> For both <xsl:if> and <xsl:choose>, the Boolean expression is simply an XPath expression which is converted to a Boolean value.

Important Boolean values can only have one of two choices: True or False, yes or no, on or off, 1 or 0, etc. The expression is converted to a Boolean according to the following rules: If the value is numeric, it's considered false if it is 0. If the number is any other value, positive or negative, it is true. If the value is a string, it is true if its length is longer than 0 characters. If the value is a node-set, it is true if it's not empty, otherwise it's false. Any other type of object is converted to a Boolean in a way that is dependent on the type of object. For example, this expression would be considered true if there were a <name> element that is a child of the context node, otherwise it would be false: <xsl:if test="name"> <xsl:if> is the simpler of the two conditional processing constructs. It evaluates the expression in the test attribute, and if it is True the contents of the <xsl:if> element are evaluated. If the test expression is not True, the contents of <xsl:if> are not evaluated. For example, consider the following:

<xsl:if test="name">Name encountered.</xsl:if> If there is a <name> element that is a child of the context node, then the text "Name encountered." will be inserted into the result tree. If there is no <name> child of the context node, then nothing will happen. Important Note that <xsl:if> does not change the context node, the way a template match does. That is, even if the test expression evaluated as true, and we entered the <xsl:if> element, <name> would not be the context node; the context node would still be whatever it was before we evaluated the test expression <xsl:choose> provides a bit more flexibility than <xsl:if>. It allows us to make any one of a number of choices, and even allows for a "default" choice, if desired. For example: <xsl:choose> <xsl:when test="salary[number(.) > 2000]">A big number</xsl:when> <xsl:when test="salary[number(.) > 1000]">A medium number</xsl:when> <xsl:otherwise>A small number</xsl:otherwise> </xsl:choose>

If the <number> element contains a numeric value which is greater than 2000, then the string "A big number" will be inserted into the result tree. If the number is greater than 1000, the string "A medium number" will be inserted, and in any other case the string "A small number" will be inserted. (Notice that we use an XPath function, number(), to convert the value in the <number> element to a numeric value. Remember, all of the text in an XML document is just that-text. XSLT won't treat the data as anything else until we tell it to. If we hadn't used the number() function, and let XSLT treat the text as text, then any value would evaluate to True, as long as it was greater than 0 characters.) In this code fragment, we escaped the " > " signs using " & gt;". This isn't strictly necessary, since " > " characters are allowed in XML as-is; however, " < " characters are not, and this often trips people up when writing stylesheets. Many people consider it a good practice to always escape both " > " and " < " characters, just to be consistent. Note that for the <xsl:otherwise> to be evaluated, any of the following could be true: <number> could contain a numeric value, which is less than 1000 There could be no <number> node where we specified it in our test expression <number> could contain text, instead of a numeric value. If the number() function is passed text which isn't a number, such as "John", it returns the special "NaN" value, which stands for "Not a Number". NaN evaluates to false, when treated as a Boolean.

That is, none of the other tests in the stylesheet can pass the test attribute, for any reason. In an <xsl:choose>, as soon as one of the test expression evaluates to true, and the XSLT processor is done executing the <xsl:when>, control leaves the <xsl:choose>. So even if two of the <xsl:when> test expressions would evaluate to true, only the first one will be processed, and control will leave the <xsl:choose> without evaluating the second <xsl:when>. If we had written our example like this instead: <xsl:choose> <xsl:when test="number[number(.) > 1000]">A medium number</xsl:when> <xsl:when test="number[number(.) > 2000]">A big number</xsl:when> <xsl:otherwise>A small number</xsl:otherwise> </xsl:choose> then the second <xsl:when> would never get called, since any numbers which are greater than 1000 would cause the first <xsl:when> to be true. The <xsl:otherwise> is not mandatory in an <xsl:choose>. If it is not included, and none of the <xsl:when> test expressions evaluates to true, then control will leave the <xsl:choose> without inserting anything into the result tree.

Try It Out-Conditional Processing in Action Let's imagine that we have a database of a company's employee information. The database can return the information in XML form, like so: Conditional processing in action.doc

<xsl:for-each> In many cases there is some specific processing that we want to do for a number of nodes in the source tree. For example, in the Try It Out section that demonstrated <xsl:element>, we had processing that we needed to do for every <name> element. So far we've been handling this by creating a new template to do that processing, and then inserting an <xsl:apply-templates> element from where we wanted that template instantiated. But there is an alternative way to do this kind of processing, using <xsl:for-each>: <xsl:for-each select="XPath expression"> The contents of <xsl:for-each> form a template-within-a-template; it is instantiated for any node matching the XPath expression in the select attribute. For example, consider the following: <xsl:for-each select="name"> This is a name element. </xsl:for-each> This "template" will be instantiated for every <name> element that is a child of the context node. In this case, all the template does is output the text "This is a name element.“ Because <xsl:for-each> is a template, it also changes the context node, as does a regular template. For example, consider the following XML:

<names> <name> <first>John</first> <last>Doe</last> </name> <name> <first>Jane</first> <last>Smith</last> </name> </names> . We could create HTML paragraphs for each <first> element, using a template like this: <xsl:template match="names"> <xsl:for-each select="name"> <xsl:value-of select="first"/> </xsl:for-each> </xsl:template> When the template is instantiated, the context node is changed to the <names> element. So our <xsl:for-each> element need only specify <name> in the select attribute, as it's a child of this context node. Then, inside the <xsl:for-each>, the context node is changed again, to <name>. So the select attribute of the <xsl:value-of> only needs to specify the <first> element, as it's a child of this new context node.

Try It Out- xsl:for-each> in Action To demonstrate <xsl:for-each>, let's rewrite an earlier stylesheet, which transformed an attributes-only document to an elements-only document. The original stylesheet was this (which we saved earlier as AttsToElems.xsl): XSL for each in action.doc

How It Works This stylesheet seems a bit simpler than the first one; it is much more straightforward and maintainable. We now only have two templates, instead of three, since the template that was used for <name> elements has now been moved up into the first template. If we look closely at the <xsl:for-each>, which is highlighted in the code, we might notice that the contents are exactly the same as the template we replaced. Remember, for all intents and purposes <xsl:for-each> is a template. The only difference between using <xsl:for-each> and <xsl:template> is that <xsl:for-each> can be inserted into other templates, whereas <xsl:template> must stand on its own.

Copying Sections of the Source Tree to the Result Tree In many cases the result tree from our XSLT stylesheets will be very similar to the source tree. Perhaps there will even be large sections that are exactly the same. XSLT provides a couple of elements that you can use to copy sections of the source tree directly to the result tree, for these occasions.. <xsl:copy-of> The <xsl:copy-of> element allows us to take sections of the source tree and copy them to the result tree. This is much easier than having to create all of the elements/attributes manually, and then copying the values using <xsl:value-of>, especially if we don't know ahead of time what the source tree will look like. The syntax is as shown: <xsl:copy-of select="XPath expression"/> The element is quite easy to use. The select attribute simply specifies an XPath expression pointing to the node or node-set required, and that node or node-set is inserted directly into the result tree, along with any attributes or child elements.

Try It Out-<xsl:copy-of> in Action As a simple example of <xsl:copy-of>, let's re-examine our employee.xml document. We've already seen how to use the FullSecurity attribute to specify when to include the information from our <salary> element when creating HTML output. But what if we have another application that needs to use the raw XML, and we can't trust it to do the right thing with our security? It would be better to create an XSLT stylesheet which will remove <salary>, under the right conditions, before the other application even gets to touch it. So let's create one. XSL copy of in action.doc

How It Works The first thing our template does is to check the FullSecurity attribute. If it's true, we call <xsl:copy-of> with the select attribute set to "/". This copies the entire document root, including all of its children and attributes, to the result tree. However, if the attribute is false, we need to copy all of the nodes except for the <salary> element to the result tree. This is done using the <xsl:for-each> element, to loop through all of the child elements of the <employee> element that are not the <salary> element. (If you look at the select attribute, it selects all children of the <employee> element, using "employee/*". But it then further filters that, to select only the ones that aren't <salary>, using "[not(self::salary)]".) The not() XPath function is a special Boolean function, that returns the reverse of whatever is passed to it. That is, if the expression would have evaluated to true, then not() will return false, and vice versa. In this case, we're creating an XPath expression that will create a node-set, containing all of the nodes which are not a <salary> node.

There is also an XPath function called true(), which always returns true, and one called false(), which always returns false. These functions are most often useful when debugging stylesheets. This is one of the few places where the self axis is used, and it might seem a little strange. What we are saying is "if there is not a <salary> element in the self axis", and since the only node which is ever in the self axis is the context node, we're really checking this node's own name! Instead, we could have written that XPath as "[not(local-name(.) = 'salary')",] which would have had the same effect. However, XSLT programmers use the construct we used in our stylesheet quite often, so it's good to see it in action, so that you won't be confused if you ever see it in a real-life stylesheet. Each of these nodes is then copied to the result tree using <xsl:copy-of>.

<xsl:copy> Similar to <xsl:copy-of> is the <xsl:copy> element. It allows much more flexibility when copying sections of the source tree to the result tree: <xsl:copy use-attribute-sets="att set names"> Instead of providing a select attribute, to indicate which section of the source tree to copy, <xsl:copy> simply copies the context node. And, unlike the <xsl:copy-of> construct, children and attributes of the context node are not automatically copied to the result tree. However, the contents of the <xsl:copy> element provide a template where you specify the attributes and children of the node which will go into the result tree. For example, if we have our good old <name> XML: <?xml version="1.0"?> <name> <first>John</first> <middle>Fitzgerald Johansen</middle>. <last>Doe</last> </name> we could create a template that looked like this: < xsl:template match="name"> <xsl:copy/> </xsl:template>

The output of this would be: <name/> since none of the children would be copied. However, we could modify the template to look like this: <xsl:template match="name"> <xsl:copy> <blah><xsl:value-of select="."/></blah> </xsl:copy> </xsl:template> in which case the output would look like this: <name><blah> John Fitzgerald Johansen Doe </blah></name> Remember, when you use "." for the select attribute in <xsl:value-of>, you get the contents of the context node plus any descendants. What we have done in the second example is to copy the context node, which in this case is the <name> element, created a child element called <blah>, and populated it with the text from <name> and its children.

Try It Out-<xsl:copy> in Action Let's redo the style sheet from the last Try It Out, using <xsl:copy> instead of <xsl:copy-of>, and using a fancy tactic called recursion . Recursion is a methodology whereby a function can call itself, which can then call itself again, etc. Of course, in the case of XSLT, instead of creating recursive functions , we would create recursive templates . These recursive templates are used quite a lot in XSLT, so it would be a good idea to start learning about them. XSL copy in action.doc

Sorting the Result Tree Sorting in XSLT is accomplished by adding one or more <xsl:sort> children to an <xsl:apply-templates> element, or an <xsl:for-each> element: <xsl:sort select="XPath expression" lang="lang" data-type="text or number" order="ascending or descending" case-order="upper-first or lower-first"/> The select attribute chooses the element/attribute/etc. by which you want the XSL processor to sort. If more than one <xsl:sort> child is added, then the output is sorted first by the element/attribute/etc. in the first <xsl:sort>, and if there are any duplicates they are sorted by the element/attribute/etc. in the second, and so on. If the XSL processor goes through all of the <xsl:sort> elements, and there are still two or more items with identical results, they are inserted into the result tree in the order in which they appear in the source tree.

The data-type attribute specifies whether the data you are sorting is numeric or textual in nature. For example, consider the numbers 1, 10, 5, and 11. If we sort these with data-type specified as "text", the result will be 1, 10, 11, 5. But if we sort numerically, with data-type specified as "number", the result will be 1, 5, 10, 11. The default is "text". The order attribute specifies whether the result should be sorted in ascending or descending order. The default is ascending. The case-order attribute specifies whether uppercase letters should come first, or lowercase letters should come first. For example, if case-order is "upper-first", then "A B a b" would be sorted as "A a B b", and if case-order is "lower-first", it would be sorted as "a A b B". The default value for case-order depends on the lang attribute, which specifies the language this document is in. (When lang is set to "en", the default case-order is upper-first.

Try It Out-<xsl:sort> in Action To demonstrate sorting with <xsl:sort>, let's sort our simple names XML. xsl sort in action.doc

Xml

More Related Content

What's hot (20)

Viewers also liked (20)

Similar to Xml (20)

More from Venkat Krishnan (7)

Xml