Had meant this to go to the list.
> On Sat, Jan 15, 2011 at 10:04 PM, Uche Ogbuji <uche@ogbuji.net> wrote:
>
> > I agree with the above until the last point. I also believe that the
> > "streamable" subset of XPath 1.0 is useful, though of course people
> > establish such a subset in several ways. I'd say XSLT 1.0's pattern
> > language comes close enough for most uses.
>
>
On Sat, Jan 15, 2011 at 11:52 PM, John Cowan <johnwcowan@gmail.com> wrote:
>
> Now that's a *very* interesting idea: the path would allow / and //,
> and the legal path steps are: name, *, @name, @*, text(), and
> id(name). That's very close to my original proposal. But patterns
> are no simpler than XPath 1.0 for the implementor, because *any*
> expression can be a predicate in a pattern, so you end up having to
> implement the whole of 1.0 anyway. What is the simplest set of
> predicates that could possibly work?
>
Well I might as well offer my own take on that matter.
The predicates bit from
http://www.xml3k.org/Amara/Architecture/Streaming_XPath
>
Is:
- numerical predicates
-
e.g. a[1]
- a numerical or positional predicate is only allowed in a step using
the child axis
-
e.g. these are *forbidden*: a/descendant::b[2] and
a/descendant-or-self::b[2]
-
but this is OK: a//b[2] since it expands to
a/descendant-or-self::node()/child::b[2] and hence the predicate is
on a step using the child axis
- predicates that only use the attribute or self axis for value
comparison
-
e.g. a[@attr = 'value']
- Boolean expressions in predicates
-
e.g. a[@id='1' or @id='2'], a[@id='1' and @spam='eggs'],
a[@id='1' and not(@spam='eggs')]
There might be some quirks/holes in the above, and I might as well have
those pointed out here as anywhere else.
-- 
