W3C home > Mailing lists > Public > public-annotation@w3.org > July 2015

Re: [web-annotation] avoid constraining HTTP

From: Ivan Herman via GitHub <sysbot+gh@w3.org>
Date: Wed, 08 Jul 2015 09:01:19 +0000
To: public-annotation@w3.org
Message-ID: <issue_comment.created-119505314-1436346078-sysbot+gh@w3.org>

> On 08 Jul 2015, at 09:23 , Erik Wilde <notifications@github.com> 
> @iherman, why would a client want to "identify a server to be an 
annotation server"? does a browser have to "identify a server to be an
 (image|script|form) server" that implements a special flavor of HTTP?

I do not think this is a fair comparison. Browsers are, in this sense,
 general purpose pieces of software and their role is to accept and do
 something with practically any type of data that is accessible 
through HTTP. As a consequence (although not only for that reason of 
course) they are a formidably complex pieces of software.

The goal in our case is to strive for simplicity. Ie, an annotation 
client should know about annotation related structures that we define,
 and nothing else. It should not take years of development efforts to 
do it, it should be simple. That means it does have a very restricted,
 or, if you like, focused knowledge of the world.

Anything that goes on through the Annotation protocol (or LDP 
protocol, for that matter) can be interpreted by a generic HTTP 
client/server. And that is fine. But only specific content of the 
information flowing through is handled by the LDP or the Annotation 
client in a specific way. What these specification define is that 
extra 'constraint' on what goes through the wire to achieve a specific
 functionality. I do not see what is wrong with that, I must admit.

> that would be rather bad and fragment the web. instead, you use HTTP
 constructs to get the job done, either what's in the vanilla spec 
using media types that work for you, or you mix in extra parts such as
 additional HTTP header fields that help to get the job done better. 
everything else is non-webby, and it would be sad to see a W3C spec go
 this way. HTTP is the application protocol of a web service, and 
trying to define "extended subsets" of it is a rather unfortunate 
> and yes, i do have a hard time seeing the sense of the whole spec as
 it is. document the way in which you're using the standard parts of 
web architecture you're using (media types, header fields, link 
relations, and so forth), and that's it. if you feel like you need 
extra parts that don't yet exist, define them in the same way as LDP 
defines Accept-Post (http://www.w3.org/TR/ldp/#header-accept-post) 
because the group felt the need to expose that specific information.
> —
> Reply to this email directly or view it on GitHub.

Ivan Herman, W3C
Digital Publishing Activity Lead
Home: http://www.w3.org/People/Ivan/
mobile: +31-641044153
ORCID ID: http://orcid.org/0000-0003-0782-2704

GitHub Notif of comment by iherman
Received on Wednesday, 8 July 2015 09:01:21 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:37 UTC