Product Description

Referring to specific information inside an XML document is a little like finding a needle in a haystack: how do you differentiate the information you need from everything else? XPath and XPointer are two closely related languages that play a key role in XML processing by allowing developers to find these needles and manipulate embedded information. XPath describes a route for finding specific items by defining a path through the hierarchy of an XML document, abstracting only the information that's relevant for identifying the data. XPointer extends XPath to identify more complex parts of documents. The two technologies are critical for developers seeking needles in haystacks in various types of processing. "XPath and XPointer" fills an essential need for XML developers by focusing directly on a critical topic that has been covered only briefly. The book offers practical knowledge of the two languages that underpin XML, XSLT and XLink. XPath and XPointer cuts through basic theory and provides real-world examples that you can use right away. Written for XML and XSLT developers and anyone else who needs to address information in XML documents, the book assumes a working knowledge of XML and XSLT. It begins with an introduction to XPath basics. You'll learn about location steps and paths, XPath functions and numeric operators. Once you've covered XPath in depth, you'll move on to XPointer - its background, syntax, and forms of addressing. By the time you've finished the book, you'll know how to construct a full XPointer (one that uses an XPath location path to address document content) and completely understand both the XPath and XPointer features it uses. "XPath and XPointer" contains material on the forthcoming XPath 2.0 spec and EXSLT extensions, as well as versions 1.0 of both XPath and XPointer.

Product Details

• Amazon Sales Rank: #368725 in Books
• Published on: 2002-07-31
• Original language: English
• Number of items: 1
• Binding: Paperback
• 208 pages

From the Publisher
Referring to specific information inside an XML document is a little like finding a needle in a haystack. XPath and XPointer are two closely related languages that play a key role in XML processing by allowing developers to find these needles and manipulate embedded information. By the time you've finished XPath and XPointer, you'll know how to construct a full XPointer (one that uses an XPath location path to address document content) and completely understand both the XPath and XPointer features it uses.

About the Author
John E. Simpson's forte is taking obscure bits of technical information and making them accessible. He is the author of Just XML, now in its second edition, and Just XSL (Prentice Hall), as well as XML.com's monthly XML Q&A column. John has been working with XML, XSL, and XPath since the technologies first emerged.

Excerpted from XPath and XPointer by John E. Simpson. Copyright © 2002. Reprinted by permission. All rights reserved.
Chapter 3 - Location Steps and Paths

In Chapter 2,I covered the kinds of content XPath is capable of locating:essentially, any content at all in an XML document.Now it ’s time to take a look at how exactly you locate it —a look,in short,at XPath syntax.

XPath Expressions
As earlier chapters (notably Chapter 1)have explained,knowing XML’s own syntax does not prepare you for knowing XPath syntax.Unlike the languages that make use of XPath,XPath itself is not an XML vocabulary.A given "XPath "doesn’t contain all the characteristic left and right angle brackets,ampersands,and other hallmarks of XML syntax dear (or not)to your heart from your other XML work.

Instead,units of XPath meaning,called expressions ,are typically used in attribute values.Thus you ’ll be creating and using XML code that uses these expressions in ways such as:

and:

Table of Contents

Sometimes,when you see the term XPath expression ,what ’s being referred to is simply a speck of meaning —a subatomic particle,as it were,that has a sort of abstract academic interest but little practical value by itself.This sort of expression is a string or numeric value.For instance,both of the following are valid XPath expressions in this limited sense:

"I should have been a pair of ragged claws"
119.725

In the real world of XPath,though,such literal expressions are pretty pointless.If you locate the literal string "I should have been a pair of ragged claws,"you simply locate that string —outside the context of an XML document or,for that matter, devoid of any context at all.XPath expressions are meant primarily to locate content in context .The most familiar real-world analogy for the syntax to accomplish this is a computer ’s filesystem or a web server ’s directory structure.

Although I probably sounded scornful just now of literal-valued Xpath expressions,don’t write them off.The ability to "find "a literal value (instead of a chunk of content in the source document)is actually quite useful.You ’ll see many examples later in this chapter, particularly in the section on the predicate portion of an XPath expression. There,you ’ll learn how to locate a particular node (represented by a location path)when its value equals,say,some particular literal value.

There ’s no way to represent the righthand side of this equation other than with a literal XPath expression.The point is merely that locating the literal value itself is absurd.

The Filesystem Analogy
In Chapter 2,Figure 2-1 depicted the structure of a well-formed XML document. Although I didn ’t make the comparison explicit,you may have observed that Figure 2-1 could also represent a directory tree:there ’s a root directory, beneath which you find one or more subdirectories,and so on.Within any directory along the way you might find one or more files.

The analogy between locating files and other resources on the one hand and XML-based content in a document on the other is not just abstract but explicit,codified in the syntax. An expression such as the following might be a perfectly legitimate Xpath expression as well as a path to one or more files in a computer filesystem:

/root/dir1/dir1_1/file

If you ’re dealing with a computer operating system or a web URI,this entire syntactic construct is called (among other things)a directory path;in XPath,it ’s known as a location path .

Points of Similarity, Points of Difference

Before getting into the nuances of location paths in their own right,I want to make plain some of the ways in which they are both similar to and different from directory paths. First, the similarities:

•Most obviously,the syntax is very similar.Each incremental move through the tree of directories or nodes is separated from others by a slash,/.
•The most common way to move through the directory or node tree is down: start at the root,select one of its children,then one of that child’s children, and so on,until finding the resource at the very end of the path.
•Both a directory path and a location path can begin with a slash,in which case they ’re referred to as absolute paths.They can also dive right in with the name of some subordinate resource,with no leading slash,and in this case,they ’re called relative paths. What they ’re relative to is "wherever you are "in the filesystem or document in question.
•A syntactically correct path is no guarantee that you ’ll find anything there. When navigating —or attempting to navigate —a directory path to a resource that doesn ’t exist,you get a "File does not exist "error message from the operating system,or an HTTP 404 message from the web server;an XPath expression that "locates "a nonexistent resource fails less egregiously,but fails nonetheless: it returns an empty node-set. And now the chief differences,neither of them obvious from the simple example already presented:

•Within a filesystem,you can easily "move up "or "move down "the directory tree to related resources (directories or files)in the same branch of the directory tree."Moving sideways "isn ’t so easily accomplished,though,especially if you need to "move sideways "to different branches of the tree and/or to other resources whose names share nothing in common.XPath,as you will see,is amazingly flexible in terms of its knowledge of a document ’s tree of nodes and the multiple relationships a given node has with others.
•While you can use wildcard characters such as *and ?to locate files that share some common naming characteristics,you cannot locate files that share the same type if their names share nothing in common.For instance,it ’s become common to name text files with a filename extension of .txt .Using this ad-hoc and totally unofficial "standard," however,both fails to locate text files with some other extension and possibly locates some non –text files as well.That is,the name is no absolute guarantee of the type. XPath,in contrast,can easily locate types of content in a given document,as well as content with specific names.

Customer Reviews

A good book - if you need that level of detail!
On the whole, this is a well-researched and well-written book, although the chapters on XPointer could do with more concrete examples of how XPointer could be used, and also more clarity in places. The chapters on XPath are good, but are marred by two things. Firstly, the level of uncertainty about the details of the impending XPath 2.0 specification. And secondly, the function reference is not as good as it could be. The material on nodes, node-sets, location steps, paths and axes is excellent. However, before buying this book, you would be advised to check that the information you need is not covered elsewhere. For example, if you're interested in XSLT, then the level of XPAth detail in 'XSLT' by Doug Tidwell is probably enough. Oddly, the function reference in Tidwell's book is superior to Simpson's.

Lots of room for improvement
I've been working with this book for a couple of weeks now and have to say that I am really disappointed. It's way too concept-heavy and there are nowhere near enough examples. The examples there are given are too general.

Looking at how thin this book is makes me wonder whether its existence is a calculated effort to rip off developers interested in learning more about the subject. I could have learned all this book has to say about XPath and XPointer concepts from reading various tutorials on the web.

The book has the feel of being slapped together quickly in an effort to rush it to market, which is a pity because it has lots of potential. The index in particular is extremely poor. I've lost count of how many times I've tried to look something up that I know I've read in the book but is not in the index.

Simpson can write, but he has the unfortunate tendency to use absurd sentences like "Don't fret; there are more detailed examples aplenty throughout the rest of the book", which, besides being untrue, leaves one with the feeling being lectured by a cowboy.

Save your money, I wish I had.

Excellent for XPath 1.0
Like reviewer "A reader", I've been working with this book for a couple of weeks now, but unlike that reviewer I can say I'm VERY happy with this book.

I needed some detailed explanations about XPath 1.0 as I'm using Vbscript & Microsoft's DOM implementation (Microsoft do not yet support XPath 2.0).. I've been through 5 other books & countless web pages seeking a proper understanding and some examples of what's possible, without much success.. until I read chapters 1 - 5 of this book (ch6 is XPath 2.0, the remainder is XPointer). Worth every penny!

I could not agree with the previous reviewer less.. the book is well written, has plenty of easy to follow examples, is very thorough, and definitely does NOT feel like a "calculated effort to rip off developers".

I as so glad I decided to ignore the reviews in this case and buy the book anyway.