[web-annotation] Dis/Allow both hasState and hasSelector on same SpecificResource?

azaroth42 has just created a new issue for 
https://github.com/w3c/web-annotation:

== Dis/Allow both hasState and hasSelector on same SpecificResource? 
==
Assuming #195, there are two options:

1. Require refinedBy as the only way to have both a State and 
Selector. 
2. Allow both on the SpecificResource, as well as refining them. 

I prefer 2, for the following reasons:
 * You could never reuse a State, as the selectors would always apply.
 This seems a shame, as HttpRequestState is very easy to reuse (here 
are my default headers).
 * Inconsistent with Style, Purpose, Scope and Rendering which all 
associate with the SR, and fit into the workflow.
 * Inconsistent with existing implementations, whereas refining is a 
new feature [really an improvement/simplification of an old feature 
that was too complex to implement]
 * It would not allow for optional States. E.g. TimeState lets you say
 "here is where you can get the exact version I saw" ... but chances 
might be very good that you can just use the source URI if the 
representation doesn't change frequently or significantly
 * Choice of State would mean repeating the Selector(s) on each of 
them. This would either make our tree into a graph (and we'd need to 
be clear about where you can shortcut), or be very repetitive.
 * I think, along with @nickstenning and @tilgovi I believe, that the 
most effective way to represent this is to describe as much as 
possible and let the advanced clients figure out what they can do and 
the less advanced just trundle their way through the options until 
they get something that works or that they understand. The more 
explicit and fixed the workflow is, the less room there is for 
innovation around robust anchoring problems that we know we haven't 
solved.


Please view or discuss this issue at 
https://github.com/w3c/web-annotation/issues/205 using your GitHub 
account

Received on Friday, 22 April 2016 17:21:37 UTC