Re: [web-annotation] Request header and language negotiation

@r12a, that is all correct and o.k., but I do not think it is all that
 relevant for the particular item in this spec. 

You can regard 'State' (as well as Selectors) as some sort of fragment
 identifiers on steroids. Instead of having a very simple way of 
identifying a particular part of a resource (the `#...`) we try to add
 more. The State allows a certain level of control of the HTTP request
 when it is issued on the core URL. What can be controlled, in this 
sense, is what goes in the request header; that is what 'Request 
Header State' does. It is a one step control over the request, 
incomplete as it may be. (Note that there is a similar issue with the 
time version of state: the request may have information about the time
 range to request a particular version in time of a resource; there is
 no guarantee that the server can honour that request.)

While it is correct that the request header's state may not provide 
all the necessary information for language negotiations, there is _no_
 claim that it does either. Some aspects may require the 
implementation, the particular usage, etc, to process the result 
further, but that _is_ out of scope at that point. For some usages a 
further refinement through, say, CSS selectors (or other) may be 
possible; I am not sure. But I maintain that this current issue is out
 of scope for this particular spec at this particular point. Hence the
 issue should remain closed.

(Note that handling the return header is not as easy as I would have 
thought. I learned at the F2F meeting that a JS script running in a 
browser has major difficulties getting hold of the response header. 
Sounds crazy, but there we are...)

-- 
GitHub Notification of comment by iherman
Please view or discuss this issue at 
https://github.com/w3c/web-annotation/issues/220#issuecomment-220754436
 using your GitHub account

Received on Saturday, 21 May 2016 02:44:59 UTC