[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: XML Encoding of XPath: Examples
- From: Wayne Steele <firstname.lastname@example.org>
- To: email@example.com, firstname.lastname@example.org
- Date: Thu, 15 Mar 2001 11:16:17 -0800
>From: Eric van der Vlist <email@example.com>
>Subject: Re: XML Encoding of XPath: Examples
>Date: Thu, 15 Mar 2001 17:58:32 +0100
>Wayne Steele wrote:
> > I propose an optional XML Encoding for XPath expressions.
> > I just posted a DTD; here's some usage examples to help clarify things.
> > Questions/Comments/Errata welcome.
>It's a neat proposal!
>I have some questions:
>Having used HP polish notation a lot in my early days, I would have
>thought of an XPath expression as a stack and would have embedded the
>location steps instead of keeping them at the same level...
That was my original thought.
Modeling Location Steps as functions, and using a prefix notation.
I ended up with something like
I didn't like the need to specify where the initial context is resolved,
somewhere deeply nested in the XML.
I couldn't think of a clean way to handle predicates.
I also noticed that the 'child' node above would never have any siblings, so
nesting didn't seem to really express the logical structure of XPath.
XPath defines a Location Path expression as a _series_ of location steps.
Each one operates on the output of the previous one.
A flat sequence of elements seems like a good way to express that, as well
as keeping the 'look' of XPath.
It also lets me reserve child elements for predicates, without having to
create a <predicate> element to muddy the waters.
>Can you give examples of location steps within conditions ?
>(such as child::chapter[section/title="XML Encoding of XPath"])
I think you've got me there.
The examples I gave all have (at most) a single-step path expression inside
Perhaps I need a wrapper element for an XPath Location Path.
Then I could do:
<literal>XML Encoding of XPath</literal>
This would also give you something to use for the documentElement of an
XPath expression, so they can be always well-formed.
>Wouldn't it be a good idea to extend it to encode XPointer ?
One thing at a time.
> > -Wayne Steele
Thanks for your comments.
I dare anyone to give me an XPath expression I cannot encode this way.
Or alternately, an XML Encoded XPath document that doesn't have an
unambiguous XPath syntax.
Get your FREE download of MSN Explorer at http://explorer.msn.com