RE: Comments on the Triple Patterns Fragments draft

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

Right


> 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
@markuslanthaler

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