On Thu, Jan 13, 2011 at 10:01 PM, Liam R E Quin <> wrote:
> At any rate,
> the ability to return non-nodes was a much-asked-for thing; the general
> trend seemed to be to want the language to be simpler, in having fewer
> odd quirks, and more flexible. The type system and a few other added
> features ended up making it noticeably larger, but there's good in there
> too...
I got curious just how much larger. On my system, the XPath 1.0
document, which also documents the data model and the available
functions, is 37 pages. XPath 2.0 + XDM + F & O is 367 pages. That's
an order of magnitude larger, rather than just "noticeably" so.
Again, I doubt if I can write down a coherent XPath subset in 3.7
pages, but it would be interesting to try.
On Fri, Jan 14, 2011 at 9:58 PM, James Clark <> wrote:
> The only subset of XPath 1.0 that makes sense to me is one that has the goal
> of being able to create one path that uniquely identifies any element (and
> perhaps attribute) in a document. Something like
> /foo[2]/bar[1]/baz[3]
Well, that's something worth having for sure, and even treating
specially, because it can be made to return a single Element rather
than an iterator.
On Sat, Jan 15, 2011 at 10:04 PM, Uche Ogbuji <> 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.
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?
--
GMail doesn't have rotating .sigs, but you can see mine at
http://www.ccil.org/~cowan/signatures
