Do we need to redefine Range Selector?

[iherman]

(Taken over from @tcole3’s comment)

[iherman]

I would argue that we do not, at least we do not if we have a multi selector, since the use cases addressed by extending the Range Selector look to me like a subset of the use cases that can be expressed using the multi selector. Again this warrants discussion.

(From @tcole3’s comment)

[iherman]

I am not sure I agree. Indeed, I do not think it can be expressed with Multi Selectors: indeed, the RangeSelector definition includes the statements that a selection "begins" at the first one either until the beginning of the end selector as one 'range' or extended for the case of multiple resources. In other words, the MultiSelector does not express the notion of a continuous "interval"-like selection.

We could extend the MultiSelector by adding attributes that suggest the continuous interval, so to say, but then we would create an overlap with the existing RangeSelection... And I do not think using such attributes is a good design in any case...

[tcole3]

The idea of start and end of a range makes sense to me in the context of a single resource (the brittleness seems acceptable). But across multiple resources, the meaning of start and end is dependent on reading order (of which there may be more than one) and seems less intuitive and much more brittle. Are there use cases where the distinction of continuous vs. discontinuous is critical? Would it be better to offer this as a hint rather than relying on an assumed reading order? (See also #28.) If a hint, I would argue it would be better as a binary property on Multi Selectors (e.g., continuous=true).

[iherman]

@tcole3

But across multiple resources, the meaning of start and end is dependent on reading order (of which there may be more than one) and seems less intuitive and much more brittle.

Let us forget, for a moment, the issue of intermediate resources, and consider only the two resources referred to by the start and end selectors. Can you explain where you see the problem?

My intention (may not be best expressed) is that we take the first selection and, in a way, we take the range within the same resource with the end selection being the end of the resource (file), we then take the end selector from the beginning of the resource until the end selector and, finally, we concatenate the two to provide the full selection. This is not dependent on the reading order, it is the way the first, resp. the second, selector being used for first and last.

Or do you mean reading order like English vs. Hebrew? (That might indeed require more thought, but I am not even sure the original Range Selector is entirely o.k. in this respect...)

[tcole3]

I was thinking of reading order of WP Resources. Consider a WP consisting of 4 files: chapter1.html quiz1.html chapter2.html quiz2.html

There are 2 commonly used reading orders: A. Chapter1.html+Chapter2.html+quiz1.html+quiz2.html B. Chapter1.html+quiz1.html+Chapter2.html+quiz2.html

Each Quiz consists of 10 questions. I want to select questions 5-10 of quiz1 and questions 1-3 of quiz2. According to Reading Order B, I can use a Range Selector, but not according to Read Order A. So, by using a Range Selector does that implicitly tell the consuming application that my Range Selector is tied to Reading Order B?

[iherman]

@tcole3, that is a great example. But I do not see the problem, actually. The current design makes the selection completely reading order agnostic. If you set the starting selection to select question "5", and end selection "4", then the current definition will yield questions 5-10 from quiz1, followed by questions 1-3 from quiz2. There is no reference to neither Reading Order A nor B, but this happens without an implicit assumption.

[iherman]

@tcole3

Are there use cases where the distinction of continuous vs. discontinuous is critical? Would it be better to offer this as a hint rather than relying on an assumed reading order? (See also #28.) If a hint, I would argue it would be better as a binary property on Multi Selectors (e.g., continuous=true).

First of all, there is no reliance on any reading order in the current definition... However, the real question is, indeed: use cases.

I believe the definition, in the latest draft, for the extended RangeSelector and the Multi Selector is consistent and they serve two different selections, what you call continuous and discontinuous. None of the two make reference or rely on reading order, because all resources are listed explicitly in an array, ie, with an order hardcoded in the selection. The question is, really: do we need both? We have a clear use case from @RachelComerford for the MultiResource a.k.a. discontinuous (now part of the document), and we should have something similar for the continuous case.

[tcole3]

Rather than redefine and extend RangeSelector, PR #31 restored original definition of RangeSelector and defines a new SpanSelector for describing continuous selections that span multiple embedded resources. For clarity this issue will be closed in favor of #32, Use Cases for Span Selector - Are there any?