From: Douglas Gregor (doug.gregor_at_[hidden])
Date: 2005-11-09 00:17:20
On Nov 8, 2005, at 9:49 PM, Stefan Seefeld wrote:
> Douglas Gregor wrote:
>> This is probably the case. However, one can think of places where a
>> tighter integration might give a more natural interface, e.g.,
>> xml::element_ptr books = ...;
>> xml::node_set cheap_books = books[attr("price") < 30];
>> But, like the reader interface, a library that supports something
>> like can be augmented with XPath support.
> I'm not sure I agree. While the syntax you suggest above is quite
> and probably follows the 'xpath object model' as implied by the
> XPath spec,
> the latter also specifies syntax, which your suggestion doesn't
> adher to.
We can't match the syntax precisely, of course, but we can apply a
> So, while what you suggest may be useful in itself, it isn't really
> compatible with xpath. (Think of applications such as xslt processors,
> where xpath expressions are strings embedded into attributes.)
I wasn't actually excluding the use of strings as XPath expressions.
> Note that my API already supports XPath. It may be a nice add-on to
> overload various operators for the xpath type to allow your suggested
> syntax, but I don't see this becoming really useful. It's just cute.
Have you perchance looked at Xpressive? The static constructs in it
allow static checking of regexes (because they are built with C++
operators), whereas the dynamic (from-string) constructs allow one
more flexibility. The same can occur with XPath: using some C++
operator overloading, we can have statically-checked XPath
expressions that also provide more accurate type information (e.g.,
an element-set instead of a node-set). Of course, we'll always need
to be able to fall back to strings as XPath expressions, which can
only be checked at run-time.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk