NOTE

---

At the time of this writing, the specifications for XLink and XPointer are still being reviewed, and it's possible that some of the syntax will change. The overall structure of XPointer, XPath, and XLink should not change.

XML namespaces offer a way to create names in an XML document that are identified by a Uniform Resource Identifier (URI). By using namespaces in your XML document, you can uniquely identify elements or attributes in the document. For example, consider the following XML document fragment:

<order>    <type ordertype="New"/>    <customer>       <type customertype="Rich"/>    </customer> </order>

This is a valid XML document, yet it would be difficult for an application reading this document to differentiate between the type element associated with the order element and the type element associated with the customer element. Although in this instance you could change the names of the elements in the DTD and XML document, this solution is not always possible.

Let's look more closely at how these element name problems can occur. For the most part, you want the DTDs you create to be modular, meaning that they contain definitions for only one type of information. These modular DTDs can then be combined to create more complex DTDs.

NOTE

---

Schemas are like DTDs, except they use a different syntax than DTDs and use XML to define the structure of a set of XML documents. For a detailed discussion of schemas, see Chapter 7.

For example, you could have DTDs that define the structure of the following XML documents: Customer, Order, Order Details, Product, and Category. These DTDs can be used to create Customer, Order, Order Details, Product, and Category XML documents. You can also combine these DTDs to create a single, complete order XML DTD that contains all the detailed information about an order, including the customer, order, order details, product, and category information. The most common problem that occurs when you combine DTDs is naming conflicts between elements.

If we defined the order entity in an external file named Order.dtd and the customer entity in an external file named Customer.dtd, our example order DTD might look like this:

<?xml version="1.0"?>   <!--Order -->   <!ENTITY order SYSTEM "Order.dtd">   <!--Customer -->   <!ENTITY customer SYSTEM "Customer.dtd">

When the Order and Customer entities are replaced, the DTD might look like this:

<?xml version="1.0"?>   <!--Order -->   <!ELEMENT order (id, customer)>   <!ELEMENT type()>   <!ATTRIBUTE type ordertype CDATA "Old">   <!--Customer -->   <!ELEMENT customer>      <!ELEMENT type()>   <!ATTRIBUTE type customertype CDATA "Rich">

This DTD is invalid because the type element is declared twice with two different types of attributes. This repetition is one of the potential problems of using external entities.

Namespaces enable you to solve this problem. Namespaces are defined within the elements in your XML document. If an element has child elements, the child elements can either inherit the parent's namespace or override the parent's namespace.

Let's begin our examination of namespaces by looking at prefixes. Each namespace has a prefix that is used as a reference to the namespace. This prefix must follow all the usual naming conventions for XML names as we discussed in Chapter 3. In addition, prefixes must not begin with xmlns or xml. You can't use xmlns because it's the keyword that's used to define a namespace, and xml can't be used because it's the processing instruction used to define attributes of an XML document.

Namespaces are declared within an element's begin tag. The syntax for declaring a namespace looks like this:

<namespacePrefix:elementName xmlns:namespacePrefix = 'URL'>

This particular URL does not refer to a DTD or a schema. The URL doesn't even have to point to an existing file. Its purpose is to provide a unique name to associate with the elements and attributes in the XML document. The namespace can also be identified by a URI or a URN.

Because each URL, URI, or URN is unique, using a company's URL followed by additional text should create unique identifiers for each namespace. Here is an example of this format:

<?xml version="1.0"?> <bill:message xmlns:bill='http://www.northwindtraders.com/bill'>    <bill:date>1/1/2002</bill:date>    <bill:body>Your current balance is $1,999,999.00. Please pay       immediately. Thank you.</bill:body>  </bill:message>

You can also declare more than one namespace in an element's begin tag, as shown here:

<?xml version="1.0"?> <bill:message xmlns:bill='http://www.northwindtraders.com/bill'    xmlns:body='http://www.northwindtraders.com/message'>    <bill:date>1/1/2002</bill:date>    <body:body>Your current balance is $1,999,999.00. Please pay       immediately. Thank you. </body:body> </bill:message>

In this example, the message element contains two namespace declarations: bill and body. The bill namespace is used to define the message element and the date child element. The body namespace is used to define the body child element.

A default namespace is used by an element if the element does not have a namespace prefix; this default is also used by all child elements of that element if they do not have a namespace prefix. The declaration for a default namespace looks like this:

<elementName xmlns='URL'>

Our earlier example could be rewritten using default namespaces as follows:

<?xml version="1.0"?> <message xmlns='http://www.northwindtraders.com/bill'    xmlns:body='http://www.northwindtraders.com/message'>    <date>1/1/2002</date>    <body:body>Your current balance is $1,999,999.00. Please pay       immediately. Thank you. </body:body> </message>

The first namespace is the default namespace. The default namespace is used by the message element and the date child element. The body child element still uses the body namespace.

You can also declare namespaces in the begin tag of child elements, as shown here:

<?xml version="1.0"?> <message xmlns='http://www.northwindtraders.com/bill'    xmlns:body='http://www.northwindtraders.com/message'>    <date>1/1/2002</date>    <body:body>       <customerName xmlns='http://www.northwindtraders.com/name'>          Fred Smith       </customerName>       Your current balance is $1,999,999.00. Please pay        immediately. Thank you.     </body:body> </message>

Here the customerName child element is defined by a default namespace.

You can set the default namespace equal to an empty string (""), as shown here:

<?xml version="1.0"?> <message xmlns=""    xmlns:body='http://www.northwindtraders.com/message'>    <date>1/1/2002</date>    <body:body>Your current balance is $1,999,999.00. Please pay       immediately. Thank you. </body:body> </message>

If you do this, there will be no namespace associated with elements that are not preceded by a namespace prefix.

NOTE

---

Default namespaces apply only to elements; they do not apply to attributes.

An attribute name can be used only once in an element. When you combine a namespace prefix with an attribute name, the combination must be unique. The following is acceptable:

<?xml version="1.0"?> <message xmlns='http://www.northwindtraders.com/bill'    xmlns:body='http://www.northwindtraders.com/message'>    <date>1/1/2002</date>    <body:body body:importance='High' importance='High'>Your current       balance is $1,999,999.00. Please pay immediately. Thank you.      </body:body> </message>

In this case, the first importance attribute is associated with the body namespace, and the second importance attribute is associated with the default namespace.

Remember, you can define an element name only once in your DTD. Namespaces resolve the element naming conflicts. By using namespaces, you can reference several different documents that all use the same element names.

In the preceding example, we used the tag form <body:body>. You must declare the element using this format in your DTD if a namespace is used. For example, this body element would need to be declared in your DTD as follows:

<!ELEMENT body:body (#PCDATA)>

If this declaration is used in an external DTD, all documents that reference this external DTD will need to use the name specified in the DTD (in this case, body:body).

You can use entities to enable users to decide whether they want to use a namespace, and if they do, what prefix they want to use. To do so, make the following declarations in your DTD:

<!ENTITY % ns ''> <!-- Can be overridden in the internal                        subset of a schema document to establish a                        namespace prefix --> <!ELEMENT %ns;body (#PCDATA)>

If these declarations were included in an external DTD named MessageBody.dtd, you could include the following reference in your internal DTD:

<?xml version="1.0"?> <!DOCTYPE message [ <!ENTITY % ns 'body:'> <!ENTITY messagebody SYSTEM "MessageBody.dtd">

The local declaration of the ns entity will override the declaration in MessageBody.dtd. Using this technique, each document that uses elements defined in an external DTD can create its own names for the namespace. Let's now move on to the other three specifications related to XML: XPath, XPointer, and XLink.

Identifying sections of XML documents is an essential part of using Extensible Stylesheet Language (XSL) and XPath. XSL is based on the idea of identifying sections of an XML document and transforming them according to a set of rules. XPath provides a means for identifying sections of an XML document.

XPath is based on the idea of repeating patterns. XML documents develop distinctive patterns in the way their elements are presented and ordered. For example, in Chapter 5 we put an a element within the body element of an XML document to create an anchor to the top of the document. This established a pattern in which the a element was always included within a p element and the p element was included within the body element. We also had a pattern in which the a element was included in a p element within a td element. In this instance, the a element was used as a hyperlink. Thus, the body, p, a pattern represents an anchor and the td, p, a pattern represents a hyperlink.

If you can identify these two patterns in the document, you can use XSL to transform the two a elements in different ways¡ªfor example, the hyperlinks can be underlined and displayed in a specified color, and the anchor can be made invisible in the document. Pattern identification enables XSL to find specific elements and transform them in a specified manner. We'll have a detailed discussion of XSL in Chapter 12.

You can also use patterns to select and link to specific sections of a document. For example, you could create a link that finds all of the item_name elements in a purchase order document and returns a reference to these elements. In both XLink and XSL, XPath is used to identify portions of an XML document. Let's begin with location paths.

The XPath specification is designed to address different parts of the XML document through the use of location paths. The location path provides instructions for navigating to any location in an XML document. You can use XPointer to specify an absolute location or a relative location. An absolute location points to a specific place in the document structure. A relative location points to a place that is dependent upon a starting location. If you were giving directions, an absolute location would be 12 Main Street, whereas a relative location would be drive 1 mile up Main Street from the intersection of Oak Street and Main Street. In the case of an XML document, an absolute location would be the root or the second customer element. A relative path would be the fourth child node of the root.

The entire XML document is called the document element. The document is represented as a treelike structure where location paths return sets of nodes on node axes. Movement will occur up and down these node axes.

The XPath data model includes seven possible node types: root, element, attribute, namespace, processing instruction, comment, and text. Let's look at each of these node types in detail.

root nodes

The root node is at the root of the tree. It is the parent of the document element. As mentioned, in XPath the document element contains the entire document. The root node contains element nodes. It also contains all of the processing instructions and comments that occur in the prolog and end of the document. The prolog consists of two optional parts: the XML declaration and a DTD.

element nodes

Every element in the document has a corresponding element node. The children of an element node include other element nodes, comment nodes, processing instruction nodes, and text nodes for their content. When you view an element node, all internal and external entity references are expanded. All character references are resolved. The descendants of an element node are the children of the element and their descendants.

The value for an element node is the string that results from concatenating all the character content in all the element's descendants. The value for the root node and the document element node are the same. Element nodes are ordered according to the order of the begin tags of the elements in the document after expansion of general entities. This ordering is called document order.

An element node can have a unique identifier that is declared in the DTD as ID. No two elements can have the same value for an ID in the same document. If two elements have the same ID in the same document, the document is invalid.

attribute nodes

Each element has an associated set of attribute nodes. An attribute that is using a default value is treated the same as an attribute that has a specified value. For an optional attribute (declared as #IMPLIED) that has no default value, if there is no value specified for the attribute, there will be no node for this attribute.

Each attribute node has a name and a string value. The value can be a zero length string ("").

namespace nodes

Every element has an associated set of namespace nodes, one for each namespace prefix that is within the scope of the element and one for the default namespace if it exists. This means that there will be a namespace node for the following attributes:

• Every attribute of the element whose name begins with xmlns;
• Every attribute of an ancestor element whose name begins with xmlns (unless the ancestor element has been used previously);
• The xmlns attribute, unless its value is an empty string

Each namespace node has a name, which is a string giving the prefix, and a value, which is the namespace URI.

processing instruction nodes

An XML parser ignores processing instructions, but they can be used to pass instructions to an XML application. Every processing instruction in the XML document has a corresponding processing instruction node. Currently, processing instructions located within the DTD don't have corresponding processing instruction nodes. A processing instruction node has a name, which is a string equal to the processing instruction's target, and a value, which is a string containing the characters following the target and ending before the terminating ?> characters.

comment nodes

Every comment in the XML document has a corresponding comment node. Every comment node has a value, which is a string containing the comment text.

text nodes

All character content is grouped into text nodes. Text nodes do not have preceding or following text nodes.

Each element in the XML document can be considered a point in the tree structure. These element points can be seen as having a set of axes, each containing nodes extending from the element point. For example, you could have the following XML fragment:

<message>    <customer customerID = "c1" customerName = "John Smith"/>    <customer customerID = "c2" customerName = "William Jones"/>    <order orderID = "o100" customerID = "1"/> </message>

As shown in Figure 6-1, this message element has a child axis that consists of three nodes: two customer element nodes and one order element node.

Figure 6-1. Representation of a child axis consisting of three nodes.

Thus, each axis moves through the element tree, selecting a set of nodes based on its axis type (child in this example), and places these elements on the axis. Using node axes, you can select a set of elements within the document. The syntax for an XPath node axis is shown here:

context axis::name

The name can be the name of an element, attribute, or other node. The context is the starting point of the path, which is usually the root of the XML document. The axis is the type of the axis that you want to select. As you will see, this format is extremely flexible and will allow you to select any pattern of elements within your XML documents.

The root element can be represented by a slash (/). When the root element is used as the context, it is equivalent to the document element.

XPath defines the following types of the node axis:

• child The child axis selects all children of the context element in document order.
• descendant The descendant axis contains all the descendants of the context node in document order. A descendant can be a child, a child of a child, and so on. The descendant axis does not contain attribute or namespace nodes.
• parent The parent axis contains the parent of the context node.
• following-sibling The following-sibling axis contains the following siblings of the context node in document order. A sibling is an element on the same level of the tree. If the context node is either an attribute or a namespace node, the following-sibling axis is empty.
• preceding-sibling The preceding-sibling axis contains the preceding siblings. If the context node is either an attribute or a name-space node, the preceding-sibling axis is empty.
• following The following axis contains the nodes in the same document as the context node that are immediately after the context node. Attribute, namespace, and descendant nodes are not included on the following axis.
• preceding The preceding axis contains all the nodes in the same document as the context node that are immediately before the context node. Attribute, namespace, and ancestor nodes are not included on the preceding axis.
• ancestor The ancestor axis contains all the context node ancestors, including the context node's parent, the parent's parent, and so on. The ancestor axis will store the nodes in reverse document order.
• attribute The attribute axis contains the attributes of the context node. There are three possible attribute axes. If you use the following syntax, the attribute axis will contain the value of the attribute with attributeName:

  attribute::attributeName

  In the following syntax, the attribute axis contains all the elementName elements that have an attribute with the value of attributeName:

  elementName[attribute::attributeName]

  Finally, in the following syntax, the axis contains all the elementName elements that have an attribute with the attribute-Name equal to the attributeValue:

  elementName[attribute::attributeName=attributeValue]

  All of these axes will be empty unless the context node is an element node.

• namespace The namespace axis contains the namespace nodes of the context nodes; the order will be defined by the implementation. This axis will be empty unless the context node is an element node.
• self The self axis contains only the context node.
• ancestor-or-self The ancestor-or-self axis contains the context node and all the context node's ancestors, in reverse document order.
• descendant-or-self The descendant-or-self axis contains the context node and all the context node's descendants.

When an axis contains more than one element, you can select an element by using [position()=positionNumber]. The first element is assigned a positionNumber value of 1.

The following XML document fragment will be used to demonstrate how these axes can be used:

<message>    <date>01-01-2001</date>    <customer customerID = "c1" customerName = "John Smith"/>       <order orderID = "o100"/>    <customer customerID = "c2" customerName = "William Jones" >       <order orderID = "o101"/>    </customer> </message>

As you can see, this document has a message root element, one date child element, and two customer child elements; each customer element has one order child element. Let's take a look at how an axis selects a set of nodes when it navigates through the element tree according to the instruction provided by the location path. The following table lists the example location paths and the element nodes selected based on these location paths.

Example Location Paths

Location Path	Description
/child::customer	/child selects all the children of the root (the date and two customer elements). /child::customer selects all the customer elements that are children of the root¡ªin this case, there are two customer elements.
/descendant::order	/descendant selects all the descendants of the root (the date element, the two customer elements, and the order elements). /descendant::order selects the two order elements.
/descendant-or-self::message	/descendant-or-self selects all the descendants of the root (the date element, the two customer elements, the two order elements, and the message root element). /descendant-or-self::message selects the message element.
/child::customer [attribute::customerID= c1]	Selects the customer element that has an attribute with a value of c1.
/child::customer [attribute::customerID= c1] [position() = 1]	Selects the first customer element having an attribute with a value of c1 (the first customer element¡ªwhich is actually the only customer element with an attribute value equal to c1).
/child::customer [attribute::customerID= c1] [position() = 1]/following-sibling::customer	Selects all the customer elements that are following siblings to the customer element having an attribute with a value of c1¡ªin this case, the second customer element (customerID = c2).
/child::customer [attribute::customerID= c2] [position() = 2]/preceding-sibling::customer	Selects all of the customer elements that are preceding siblings to the customer element having an attribute with a value of c2¡ªin this case, the first customer element (customerID = c1).
/following::customer	Selects the two customerelements.
/child::customer [attribute::customerID= c1] [position() = 1]/ customer preceding::date	Selects the date elements preceding the first element that has an attribute with a value of c1. Our example document has only one.
/self	Selects the message element.

XPath includes a set of terms that can be used to find patterns within an XML document. These patterns are described here:

• node Selects all child elements with a given node name
• * Selects all child elements
• @attr Selects an attribute
• @* Selects all attributes
• ns:* Selects elements in a given namespace
• node() Matches an element node
• text() Matches a text node
• comment() Matches a comment node
• processing-instruction() Matches a processing instruction node
• . (dot) Selects the current node
• .. (double dots) Selects the parent of the current node
• / (slash) Selects the document node
• // (double slash) Selects descendants and self¡ªwhich is equivalent to descendant-or-self

Note that because the default axis is child, when an axis is omitted, the child axis is used. The XML document fragment mentioned in the previous section is used to demonstrate how to use these basic patterns. The following table lists a set of example XPath patterns and the element nodes selected based on these shortcuts.

Example XPath Patterns

Location Path	Description
/customer	/ is equal to /child and selects all the children of the root (the date element and the two customer elements in our sample document). /customer selects all the customer elements that are children of the root¡ªin this case, there are two customer elements.
//order	Selects all the order elements that are descendants of the root (document) node¡ªin this case, there are two order elements.
/.//order	/.//order is equivalent to /self::node()/descendant- or-self/child/order. /self::node() is the root node, /self:: node()/descendant-or-self selects all of the descendant elements of the root and the root itself, and /self::node()/descendant-or-self/child/order selects the order elements that are descendants of the root.
/.//order[@orderID =o100]../customer	/.//order selects the two order elements. [@orderID=o100] selects the order element with an attribute named orderID that has a value equal to o100 (the first order element in the document). .. selects the parent element, /.//order[@orderID =o100]../customer selects the customer element containing the order element with an orderID attribute equal to o100.
/descendants[@customerID]	Selects all the elements that are descendants of the root element and that have a customerID attribute (the two customer elements).
/*	Selects all the children of the root element (the twocustomer elements and the date element).
/*/order	Selects all the order elements that are grandchildren of the root element (in this case, the two order elements).
//order[2]/@orderID	//order[2]/ selects the second order element, //order[2]/@orderID retrieves the value of the orderID attribute for the second order element.

XPath also contains functions. These functions will be discussed when we discuss XSL in Chapter 12.

XPointer provides access to the values of attributes or the content of elements anywhere in an XML document. Using XPointer, you can link to sections of text, select particular attributes or elements, navigate through elements, and so on. The specification does not dictate what an application will do with the information returned by the XPointer.

Unlike XPath, XPointer enables you to select information that is contained within more than one set of nodes. For example, if you are presenting a document that contains several sections of text, where each section is contained within a paragraph element, it's possible that a user may highlight text that begins in the middle of one paragraph element and ends in the middle of another paragraph element. XPath allows you to define only complete sets of nodes, and because this example includes parts of nodes, XPath can't be used to represent the section. XPointer has extensions to XPath that allow you to get a reference to the text that was selected. Any XPath expression that returns a node-set may be used with XPointer. Thus, the following XPointer expression will select all the order elements that are grandchildren of the root element (in this case, the two order elements in our example XML document):

xpointer( /*/order)

In addition to defining nodes, XPointer also defines points and ranges. The combination of nodes, points, and ranges creates locations. A point is a position in an XML document. A point location is the combination of a node, called the container node, and an index. When the container node of a point is a root node or an element node, the point is called a node point. The index must be equal to or greater than 0 and less than or equal to the number of children nodes of the container node. The index zero represents the point before any child nodes, and a non-zero index n represents the point directly after the n^th child node.

If the container node is not a root node or an element node, the point is called a character point. The index must be either zero or less than or equal to the number of characters associated with the node. The index zero represents the point immediately before the first character. A non-zero index represents a point immediately after the n^th character.

A range represents all the XML structure and content between a start point and an end point. The start and end points must be in the same document, and the start point must occur before the end point in document order. The start and end points can be located in the middle of a node. If the start and end points are at the same point, it is called a collapsed range. If the container node of the start point is a node other than an element node, a text node, or a root node, the end point must be in the same container node. The string value of a range is all of the text nodes within the range.

We can now use the XPointer to define a range as follows:

Xpointer (/child::customer [attribute::customerID= c1 to /child::customer [attribute::customerID= c2]

This XPointer selects a range starting at the beginning of the child customer element that has an attribute with a value of c1 and ending at the end of the child customer element that has an attribute with a value of c2. For our example XML fragment, the two customer child nodes are selected.

XLink provides links similar to hyperlinks. XLink enables you to define link elements in your DTD. XLink elements can have the following attributes: type, href, role, title, show, and actuate. There are two types of XLinks, simple and extended. A simple link connects two resources: a source and a destination. An extended link connects any number of resources. In this section, let's take a look at these two types and the attributes defined in XLink in detail.

A declaration for a simple XLink element might look like this:

<!ELEMENT Mylink ANY> <!ATTLIST Mylink   xlink:type    (simple)             #FIXED "simple"   xlink:href    CDATA                #REQUIRED   xlink:role    NMTOKEN              #FIXED "roleName"   xlink:title   CDATA                #IMPLIED   xlink:show    (new                 |replace                 |embed                 |undefined)          #FIXED "replace"   xlink:actuate (onLoad                 |onRequest                 |undefined)          #FIXED "onRequest" >

The attributes are defined as follows:

• type Specifies whether the link is simple or extended.
• href Refers to the URI of the other end of the link. This can be an entire document, or it can be a point or an element in a document. An XPointer can be used to identify a point in the document.
• role Describes the function of the other end of the link. There are no predefined role values. You can create your own roles that will be interpreted by your applications to define different types of XLink. For more information on roles, see the W3C specification at http://www.w3c.org/TR/2000/WD-xlink-20000221/.
• title The title attribute is the same as the HTML link title. It can be used to display floating tips or a default value when the link cannot be displayed.
• show If no style sheet is used, the show attribute will tell the application what to do with the link. The embed value causes the content of the link target to be embedded in the content of the link source. The replace value causes the content of the link source to be replaced by the content of the link target. The new value creates a new instance of the application containing the linked document. An undefined value means there is no defined behavior for this link.
• actuate Specifies when the link should be activated. The onRequest value indicates that the application will wait for the user to request that the link be followed. The onLoad value causes the link to be followed immediately. The onRequest value behaves like the HTML a element; onLoad behaves like the img element.

Extended links are similar to simple links, except they allow you to link to multiple links instead of just one link. An extended link consists of a set of linking resources and a set of connections between these resources. The linking resources may be local or remote. If all the resources are remote, the link is an out-of-line link. If all the resources are local, the link is an inline link. A local resource is contained in the extended link element and a remote resource is outside of the extended link element.

For more information about extended links, visit the specification Web site, at http://www.w3.org/TR/xlink/.

XML namespaces allow you to avoid naming collisions when you define elements and attributes using different DTDs or schemas. Namespaces can be defined with prefixes, or you can use default namespaces.

XPointer and XPath enable you to link to specific parts of an XML document. XPath can use patterns to identify sections of an XML document. XPointer allows you to do everything XPath can do, but also extends XPath to allow you to address points in the document and ranges between points. The range may not correspond to any one node. XLink enables you to create links within XML documents. In Chapter 7, we'll discuss an XML schema that enables you to validate data types, use namespaces, and check ranges of values.