W3C home > Mailing lists > Public > public-change@w3.org > March 2013

RE: XPath to identify a point in an XML document (Was: A sort of synthesis)

From: Liam R E Quin <liam@w3.org>
Date: Mon, 11 Mar 2013 19:55:16 -0400
To: dennis.hamilton@acm.org
Cc: 'Innovimax W3C' <innovimax+w3c@gmail.com>, public-change@w3.org
Message-ID: <1363046116.9930.8.camel@localhost.localdomain>
On Mon, 2013-03-11 at 15:07 -0700, Dennis E. Hamilton wrote:
[...]

> It appears that XPath can find a text node, but not a path to the
> interior of that text node.  (A text node is a string and never has
> adjacent text nodes -- it is the largest string that can be made
> without crossing a tag.)

It depends what you mean by "find" - it can return a substring; XPath 2
(and 3) can return a (node, offset) pair if you like.

>   XPath, even abbreviated XPath can be far "wordier" but it can also
> be simpler because it can short-circuit using full paths because it is
> based on a search model, not a strictly-navigational model.

SoftQuad Panorama, years ago, used the nearest element ancestor with an
ID attribute, if there was one, and navigated from there, since IDs tend
to be relatively stable across document revisions.

> For example, one advantage of an (augmented) XPath arrangement is the
> ability to find attributes via XPath.  This means that one can find
> elements by known xml:id attribute values.
Yes, indeed.
>  There are other aspects of XPath usage that might be used  easier to
> confirm that the target has what is expected there (sort of the way
> patch software often works).
Yes, one can also use contains() to check for a string, for example.

Liam

-- 
Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/
Pictures from old books: http://fromoldbooks.org/
Ankh: irc.sorcery.net irc.gnome.org freenode/#xml
Received on Monday, 11 March 2013 23:55:23 GMT

This archive was generated by hypermail 2.3.1 : Monday, 11 March 2013 23:55:23 GMT