- 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