- From: Benjamin Young <bigbluehat@hypothes.is>
- Date: Wed, 11 Nov 2015 16:44:48 -0500
- To: Randall Leeds <randall@bleeds.info>
- Cc: W3C Public Annotation List <public-annotation@w3.org>, Ivan Herman via GitHub <sysbot+gh@w3.org>
- Message-ID: <CAE3H5FJpEhcKegPGY6kuVWw+xRvJXXo7VTNPNyu-7mXYyVD8Vw@mail.gmail.com>
Awesome. I like where this is headed. https://github.com/w3c/web-annotation/issues/95#issuecomment-155919060 On Wed, Nov 11, 2015 at 12:27 PM, Randall Leeds <randall@bleeds.info> wrote: > On Wed, Nov 11, 2015 at 5:23 AM Benjamin Young <bigbluehat@hypothes.is> > wrote: > >> On Tue, Nov 10, 2015 at 5:21 PM, Randall Leeds <randall@bleeds.info> >> wrote: >> >>> .../p/node()[1] to ../p/node()[3] would select the first text node and >>> the image. >>> >>> If you wanted to select only part of the first text node than you would >>> need to further refine that. >>> >>> Since XPath to select the text would cause the evaluator to return a >>> string rather than a node, I suggested on that GH issue that a full >>> selector for each end of the range makes processing easier. A subSelector >>> on the start could refine the start point to be inside the text node. >>> >> >> In which case, this is starting to make a lot of sense. :) >> >> This would give us a way to further qualify both the beginning and end of >> a selection--while grabbing everything in between. >> >> Randall, do you have cycles to do some implementation exploration on the >> current Range and XPathSelector things we've been tossing around? >> >> > Already have been. > > The Range utilities in Annotator were factored out in the past into the > xpath-range library. I've since released a new version of it that tries to > strip it down to a simple API. > > https://github.com/openannotation/xpath-range > > Going from Range -> Selector, the original API included a way to ignore > certain nodes in the XPath expression generation. I removed that. > > Going from Selector -> Range, I tried finding a way to take just XPath > expressions, with no offsets, but realized that there was no way to do this > without having to parse out the offsets from a substring expression anyway, > so I made them explicit parameters. > > The biggest problem with this library as is is that the Range is assumed > to point to text nodes -- the offsets are treated as text offsets -- but > this isn't made clear. Instead, it should handle Range objects that have > boundary containers in Elements or Text. For the latter I would generate > sub-selectors, as I've been describing in this thread. >
Received on Wednesday, 11 November 2015 21:45:17 UTC