W3C home > Mailing lists > Public > public-hydra@w3.org > July 2014

RE: Comments on the Triple Patterns Fragments draft

From: Markus Lanthaler <markus.lanthaler@gmx.net>
Date: Wed, 23 Jul 2014 00:21:58 -0700
To: <public-hydra@w3.org>
Message-ID: <023301cfa646$cc31efe0$6495cfa0$@gmx.net>
Hi Erik,

Great to see you here!

On 22 Jul 2014 at 23:52, Erik Wilde wrote:
> 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.

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]".

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

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.

Markus Lanthaler
Received on Wednesday, 23 July 2014 07:22:43 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:29:42 UTC