Re: [web-annotation] Reference to text encoding in spec perhaps not appropriate

> Or at least that there exist a number of use cases where the text is
 later presented to a human and not merely used by a machine for 

I agree that there are use cases where snipped text is presented to a 
human, however this particular issue is about describing the text 
sufficiently accurately in the annotation's representation such that a
 second, consuming user agent can discover the correct segment in the 
full textual content. As such, rendering concerns are out of scope in 
this situation.

Further, the Specific Resource identifies the selected content, not 
the Selector, which describes how to discover the selected content.  
The SpecificResource could have a separate property (e.g. `value`) 
that contains the content to be rendered for the user. Note the 
distinction with URI Fragments, which both identify (it's a URI) and 
describe (by means of the fragment) the content. Specific Resources 
intentionally pull apart these two functions.

Regarding markup, it seems like a very slippery slope. If the 
annotated content is markdown, such as these github comments, then 
some *s are just characters and some are bullets
  * like so

We also previously agreed not to normalize whitespace in #221 after 
discussion with #i18n. There seems to be now a request to put that 
back. I don't want to flipflop unnecessarily, so can we identify the 
situations in which whitespace normalization is (a) helpful and (b) 
unhelpful?  The "if applicable" seems to be getting back into the 
fuzzy rules realm that we were trying to escape from.

GitHub Notification of comment by azaroth42
Please view or discuss this issue at
 using your GitHub account

Received on Tuesday, 31 May 2016 18:17:08 UTC