- 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
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 UTC