Re: [web-annotation] avoid constraining HTTP

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=>
>>>
>>>
>>