Re: [web-annotation] avoid constraining HTTP

I have a much wordier email in the works. ;) However, I think there's a
core point to what Erik's been saying that we might be missing for the
trees.

The Web Annotation Protocol spec as currently written requires all
implementations to support read *and* write semantics--per 4.1.1:
http://www.w3.org/TR/annotation-protocol/#http-requirements

What if I have an existing commenting system that uses HTTP forms (ala
WordPress, etc), and I simply want to make those available in the
Annotation Data Model for viewing in relation to the page--something which
right now is done via RSS and Atom feeds?

If that's all I want to do, then this protocol doc won't help me as
currently defined--because of the MUSTs in 4.1.1.

This is a scenario I think we should be ager to support--given our charter,
etc. However, Erik's correct that the protocol doc does currently tie
reading and writing into a single set of requirements--"constraining HTTP."

Rather, we should prescribe how to advertise annotation containers and use
HTTP semantics for determining if they're currently writeable using
a combination of `Allow` and `Accept`.

If writes are attempted, and fail with 405...maybe the server changed it's
mind, lied to the client, or just plain ain't that smart yet. ;) The client
should be ready for that in any case.

I think if we change the MUST's to SHOULD's in 4.1.1 and call out that this
is for enabling writeable annotation containers, we SHOULD be fine. :)

On Thu, Jul 9, 2015 at 9:12 AM, Jacob Jett <jjett2@illinois.edu> wrote:

> Well...I don't want to get side tracked by the example, it seems to me
> that what you're saying is since we have to look into the container anyway
> it doesn't actually matter if it calls itself an annotation container. Am I
> understanding correctly?
>
> If this is the case, do we need a container protocol at all? Can't
> everyone just select off-the-shelf containers and 'Bob's your uncle'?
>
> Essentially from the retrieving server's perspective, it's less the
> question of 'are you an annotation server?' and more the question of 'does
> the container I just received contain annotations in it?' Is that the crux
> of the matter? Because that seems really six of one and half dozen of the
> other.
>
> However, IMO, we need to support both approaches because we'll have
> communities of folks who will want to use one or the other of those methods
> according to their arbitrary prerogative. It seems to me that simply
> constraining HTTP is a eat the cake and still have it situation. It allows
> those who want to have specialized annotation servers to have them but
> detracts from those who want to look in the container to see if there are
> annotations not at all. So I don't see the problem here. A bigger issue is
> there may be a risk of marginalizing a section of the community interested
> in employing specialized annotation servers.
>
> Since you can still look in the container for the annotations I'm not sure
> I see how these constraints actually hurt your desired implementations. Can
> you clarify specifically what things you'll be prevented from doing?
>
> _____________________________________________________
> Jacob Jett
> Research Assistant
> Center for Informatics Research in Science and Scholarship
> The Graduate School of Library and Information Science
> University of Illinois at Urbana-Champaign
> 501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
> (217) 244-2164
> jjett2@illinois.edu
>
> On Wed, Jul 8, 2015 at 11:27 PM, Randall Leeds <randall@bleeds.info>
> wrote:
>
>>  I'm not sure that's a fair comparison, Jacob.
>>
>>  In the context of this discussion, it might be more like saying
>> McDonald's SHOULD have large golden arches outside. But if I walk into a
>> building and find a McDonald's I'm going to be able to order a Big Mac
>> whether or not it advertises itself as McDonald's outside.
>>
>>  On Wed, Jul 8, 2015 at 1:02 PM Jacob Jett <jjett2@illinois.edu> wrote:
>>
>>> I'm not sure if I follow the reasoning for SHOULD. If I buy a double
>>> quarter-pounder at mcdonald's it would be strange to find a big mac in it's
>>> package when I got home...
>>>
>>>  Does that make sense?
>>>
>>>  If I ask a server for one kind of data and then magically get another,
>>> it seems like it will be harder to build clients. Wouldn't that basically
>>> reduce us to reinventing the web browser (because I might be getting
>>> anything back from the server)?
>>>
>>>  _____________________________________________________
>>> Jacob Jett
>>> Research Assistant
>>> Center for Informatics Research in Science and Scholarship
>>> The Graduate School of Library and Information Science
>>> University of Illinois at Urbana-Champaign
>>> 501 E. Daniel Street, MC-493, Champaign, IL 61820-6211 USA
>>> (217) 244-2164
>>> jjett2@illinois.edu
>>>
>>> On Wed, Jul 8, 2015 at 2:41 PM, Randall Leeds via GitHub <
>>> sysbot+gh@w3.org> wrote:
>>>
>>>> I think the basic point @dret is making is that even if a server
>>>> doesn't advertise support for certain things the client could still
>>>> try throwing things at it and they might stick.
>>>>
>>>> But also, there seems to be a question we haven't answered here. I
>>>> think one answer motivates the MUSTs.
>>>>
>>>> Must an annotation container only contain annotations?
>>>>
>>>> Even if the answer is "yes" then I think SHOULD might be more
>>>> appropriate. If the answer is "no" then the MUST is _definitely_ not
>>>> appropriate.
>>>>
>>>> --
>>>> GitHub Notif of comment by tilgovi
>>>> See
>>>> https://github.com/w3c/web-annotation/issues/51#issuecomment-119709221
>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_w3c_web-2Dannotation_issues_51-23issuecomment-2D119709221&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=npggDwlZ6PziBzPBZthSo0f8iGOgRMf9ulO6o4WwfiA&m=wmyLA9tCplqFRsWqum4JbKvbPgdFnatOtRXXFBeOmTg&s=aqv34jW3G5VlexoZkMjxNBD4vaCj6vzIkooXM_Dhvfg&e=>
>>>>
>>>>
>>>
>