Re: Comments on the Triple Patterns Fragments draft

hello markus.

On 2014-07-23, 9:21 , Markus Lanthaler wrote:
> On 22 Jul 2014 at 23:52, Erik Wilde wrote:
>> just imagine if the web had gone this route, and HTML and other media
>> types would have hardcoded HTTP as the only acceptable way to identify
>> and interact with resources. that way, HTTPS would have violated all
>> those specs, and you also would never be allowed to use FTP or any other
>> kind of URI scheme.
> Right, but that's not what I said (at least I didn't want to). I was saying that *if* HTTP URLs are used with those hypermedia controls, *then* it is unnecessary to specify that the server handling requests to these URLs "MUST comply with the HTTP specification [RFC2616]".

i think we are in violent agreement here. *if* non-HTTP URIs are showing 
up, then maybe the client is out of luck, or maybe there's another piece 
of information somewhere that says how to use the controls with 
evenbetterthanHTTP: URIs. but if HTTP URIs are used, then well, that 
means HTTP is used by definition, and implementations supporting this 
spec over HTTP should know what to do.

>> leave it to the use of a particular URI scheme to
>> figure out how (if at all) this interaction is possible. if it isn't,
>> then at this point a client has to give up and backtrack.
> That's basically what I tried to say in my mail: the HTTP URL scheme already defines how the protocol looks like, we don't have to restate that in the Triple Pattern Fragments spec.

not only don't you have to, you shouldn't be doing it. it's implicit in 
the URIs being used. REST's uniform interface constraint allows us to 
rely on that.

i really think we're in agreement here. cheers,

dret.

-- 
erik wilde | mailto:dret@berkeley.edu  -  tel:+1-510-2061079 |
            | UC Berkeley  -  School of Information (ISchool) |
            | http://dret.net/netdret http://twitter.com/dret |

Received on Wednesday, 23 July 2014 07:37:13 UTC