- From: None via GitHub <sysbot+gh@w3.org>
- Date: Thu, 05 Nov 2015 12:39:45 +0000
- To: public-annotation@w3.org
"startPath": "substring(string(//article/p[1]), 10)"
substring(string(//article/p[1]), 10) is not a path, right?
So we need to have both the path and the offset - something like
"startPath": "//article/p[1], offset(string,10)",
On Thu, Nov 5, 2015 at 3:15 AM, Randall Leeds
<notifications@github.com>
wrote:
> What I was missing was the string function and the fact that the
> string-value of an element includes the concatenation of the
string-value
> of each of its children.
>
> Using a construction like string(/html/body/article/p[1]) would
fulfill
> my use case.
>
> So, for instance, the range that encompasses the text between the
10th
> character of the first paragraph and the 8th character of the third
> paragraph, each of the article:
>
> {
> "type": "XPathRangeSelector",
> "startPath": "substring(string(//article/p[1]), 10)",
> "endPath": "substring(string(//article/p[3]), 0, 8)"
> }
>
> The only problem with this in practice for DOM selections is that
the path
> expressions would have to be tokenized manually first since the
standard
> XPath APIs would give you a string result for each of these.
>
> For example, to process this example for the use case of
highlighting the
> resulting range, one would need to write code to parse out the
> //article/p[n] references and the substring function offsets, use
the DOM
> XPath APIs to look up the node references and then iterate text
nodes to
> find the container/offset suitable for constructing a DOM Range.
>
> That's doable, but the first step could be avoided if the startPath
and
> endPath are each selectors that point to a node with sub-selectors
that
> specify the text offsets within. It avoids the need to tokenize the
paths.
>
> I could live with it, though.
>
> —
> Reply to this email directly or view it on GitHub
>
<https://github.com/w3c/web-annotation/issues/95#issuecomment-153876212>.
>
--
GitHub Notif of comment by tbdinesh
See
https://github.com/w3c/web-annotation/issues/95#issuecomment-154047984
Received on Thursday, 5 November 2015 12:39:54 UTC