ANN: XML Encoded XPath 0.2

[Wayne Steele <xmlmaster@hotmail.com>]

I've revised my "XML Encoded XPath" (hereafter "XEXPath") proposal based on 
comments from XML-DEV and my own closer re-read of the XPath rec.

I now have:
   1. A DTD for XEXPath
   2. An XML document of sample XEXPath expressions
   3. An XSLT stylesheet to convert from XEXPath to XPath

I'll post each of these separately.

I've tested the DTD and XSLT using MSXML3.0; if anyone has problems with 
other processors I'd like to hear about it.

Several people have asked "Why do this? Are you trying to replace XPath?"

The answer is no. I like the syntax of XPath, and would hate to see it 
replaced. But from time to time, it's useful to manipulate an XPath 
expression as a pre-parsed tree. Naturally, I prefer XML to encode this 
information. Think of XEXPath as an XML serialization of an XPath 'InfoSet'; 
not as a replacement.

If you don't need such a beast, don't worry about it. But I hope some people 
will find it useful, such as for programmatic generation of XPath 
expressions, or for XPath checking software (ie XPath-lint), or Query 
Optimization.

Notes on changes from XEXPath 0.1 :

1. Since I want to suppress purely syntactical distinctions, I originally 
wanted to 'explicitize' a predicate with a bare number [x] to 
[position()=x]. Upon rereading the spec I realized that this is not a 
syntactic shortcut, but part of the behavior of a predicate. For instance, [ 
my:function( $z ) ] may well return a number, and be treated in the same 
way. Since I can't eliminate the special way predicates treat numbers, I 
figure I may as well not bother rewriting [x] as [position()=x].

2. It turns out that you can't really model a Location Path as a 
multi-rooted tree. There are cases where you may have one location path 
followed by another, and you need to keep them discrete. So I've decided to 
wrap Location Paths inside of a <compose> element; and unify this with the 
slash operator in [XPath Production 19].

3. Previously I had predicates encoded as a subtree under a Location Step; 
I've moved them out to their own element which follows the Location Step. 
This way I can unify 'Predicates in Location Paths' with 'Predicates as 
FilterExpressions' [XPath Production 20]. A predicate which is part of a 
Location Path is inside the parent <compose> element.

4. Since this removes the element content of a axis element, I decided to 
push the optional Nametest into the content. Type and nsURI remain as 
attributes. The name '*' is indicated by leaving the content empty.


Comments/Suggestions/Errata are invited.

In particular, XEXPath does not directly express NamespaceURI-Prefix 
bindings; therefore my stylesheet cannot properly translate XEXPath into 
XPath where namespace-qualified names or functions are used. Suggestions are 
invited.

-Wayne Steele



_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com