Comments on the Triple Patterns Fragments draft

Hi Ruben, all!

Great work on the Triple Patterns Fragments draft! Anyway, as is to be 
expected, I have comments. :-) 

1) RFC 2616 has been superseded by a number of new RFCs. I have yet to read 
them all myself, but I think we should follow mnot's advice to not use it as 
normative reference: https://www.mnot.net/blog/2014/06/07/rfc2616_is_dead

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

3) I really don't understand why it is required that CORS is given with a 
wildcard...? I mean, I see the point with caching, but caching is not the 
only legitimate concern on the Web... You're creating a huge minefield here 
when user credentials are involved: Surely, TPFs are not intended just for 
public resources? I feel it is a stretch to require CORS at all, again in 
the interest of orthogonal specs and unexpected reuse, there might be new 
protocols that have completely different ways to address the security issues 
that CORS addresses. I would be pretty strongly against the wildcard 
requirement, and I would be more comfortable with a SHOULD rather than a 
MUST with regards to the connection to CORS (for the record, I have a full 
CORS implemention which is on by default in my module).

4) As I was implementing LDF, I found that if I have a { ?s ?p ?o . } 
pattern, i.e. all variables, I would much rather point the user at a data 
dump. I didn't see a comment about that in there. I put in some tests:
https://github.com/kjetilk/RDF-LinkedData/blob/feature-fragments/t/18-
fragments.t#L129
My plan was to just throw a 400 in the first release, but subsequently put in 
a Location header that points to the data dump. A redirect might be more 
appropriate. I don't support paging for now. :-) Anyway, I think it would be 
interesting to deal with what I suspect to be a rather common situation, 
that a certain triple pattern is a resource with another URI already.

Anyway, great as a first draft, I look forward to implementing this!

Cheers,

Kjetil

Received on Sunday, 20 July 2014 22:24:39 UTC