Re: Comments on the Triple Patterns Fragments draft

hello markus.

On 2014-07-23, 8:35 , Markus Lanthaler wrote:
> On 22 Jul 2014 at 13:18, Ruben Verborgh wrote:
>> On 21 Jul 2014 at 14:11, Kjetil Kjernsmo wrote:
>>> 2) And oh, BTW, here I go again: Since REST is expressedly not-just-HTTP
>>> (and also, just think about the possibility that some may be able to
>>> implement the spec not-just-HTTP) I think it is inappropriate to say that
>>> "Triple pattern fragments servers are HTTP servers and hence MUST comply
>>> with the HTTP specification [RFC2616]."
>>> It is in the interest of orthogonal specifications and unexpected reuse that
>>> this is specified in terms of messages, and that HTTP is mentioned as an
>>> implementation example. IMHO. :-)
>> While I do wanted to specify an HTTP API in the first place
>> (that happens to conform to the REST architectural style),
>> I see a benefit in making this extensible.
>> On the other hand, specs should ensure interoperability.
> The MUST RFC2616 statement could be left out in any case. If HTTP URLs are used, a conformant server has obviously to conform to the HTTP specs.  Using the same reasoning, other normative statements in section 4 should be dropped (or at least made non-normative to prevent duplication of normative statements).

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.

obviously, some uses of links and media types will need certain 
interaction capabilities, and not all of those will always be available 
via all URI schemes. but that doesn't mean that you have to make specs 
so narrow that HTTP is hardcoded. simply say what kind of interaction is 
required, and then 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.

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 06:52:49 UTC