- From: Ivan Herman via GitHub <sysbot+gh@w3.org>
- Date: Wed, 30 Mar 2016 04:20:52 +0000
- To: public-annotation@w3.org
> On 29 Mar 2016, at 19:54, Rob Sanderson <notifications@github.com> wrote: > > Currently, each item in a set of states is an alternative (e.g. avoiding an explicit choice node for those states) and the same for a set of selectors, but we don't say (and should) how to interpret them. > > We used to have: > > It is expected that if a State is present, it will be processed first to ensure the correct representation is retrieved. Then, if there is a Selector, it would be applied to determine the correct segment of the representation. Finally, if there is a Style, it would be applied to ensure the correct rendering or the resource or segment. As Scopes do not affect the rendering directly, they may be processed in any way deemed appropriate for the user interface or application. > > And even further back had a workflow diagram, but it was seen as too prescriptive. > > Just a thought experiment: what if we *disallow* having both state and selector in the same place, but have refined by allowed in the way I proposed? It strikes me that the scheme you describe in that quote could be made much clearer by referring to refinedBy and imposing some (fairly understandable) restrictions, eg, not to refine a selector by a state… I have not looked at style. At first glance it looks o..k. to refine a selector by a style but not to define refinedBy for style. -- GitHub Notification of comment by iherman Please view or discuss this issue at https://github.com/w3c/web-annotation/issues/195#issuecomment-203239919 using your GitHub account
Received on Wednesday, 30 March 2016 04:20:54 UTC