W3C home > Mailing lists > Public > public-annotation@w3.org > November 2015

Re: [web-annotation] Selecting more than text

From: Benjamin Young <bigbluehat@hypothes.is>
Date: Wed, 11 Nov 2015 16:44:48 -0500
Message-ID: <CAE3H5FJpEhcKegPGY6kuVWw+xRvJXXo7VTNPNyu-7mXYyVD8Vw@mail.gmail.com>
To: Randall Leeds <randall@bleeds.info>
Cc: W3C Public Annotation List <public-annotation@w3.org>, Ivan Herman via GitHub <sysbot+gh@w3.org>
Awesome. I like where this is headed.

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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:42 UTC