Re: LDP feedback ( LC-2812)

 Dear Mark Baker ,

The Linked Data Platform (LDP) Working Group has reviewed the comments you
sent [1] on the Last Call Working Draft [2] of the Linked Data Platform 1.0
published on 30 Jul 2013. Thank you for having taken the time to review the
document and to send us comments!

The Working Group's response to your comment is included below.

Please review it carefully and let us know by email at
public-ldp-comments@w3.org if you agree with it or not before 2 December
2013. In case of disagreement, you are requested to provide a specific
solution for or a path to a consensus with the Working Group. If such a
consensus cannot be achieved, you will be given the opportunity to raise a
formal objection which will then be reviewed by the Director during the
transition of this document to the next stage in the W3C Recommendation
Track.

Thanks,

For the Linked Data Platform (LDP) Working Group,
Eric Prud'hommeaux
Yves Lafon
W3C Staff Contacts

 1.
http://www.w3.org/mid/CALcoZioKXu5npFQiXccR7faoL5vvYRt19V99xErVrUX55dZYgg@mail.gmail.com
 2. http://www.w3.org/TR/ldp/


=====

Your comment on 4. Linked Data Platform Resources:
> Hi.
> 
> I raised this issue before, but it was never resolved to my
> satisfaction, so I'm raising it again now at LC.
> 
> Sec 4.6.1 says "LDPR servers must remove the resource identified by
> the Request-URI. After a successful HTTP DELETE, a subsequent HTTP GET
> on the same Request-URI must result in a 404 (Not found) or 410 ".
> This is bad because it redefines HTTP DELETE, which already has a well
> defined meaning in RFC 2616. The definition in 4.6.1 is more specific
> than the one in 2616, and it's why you need the LDP-specific Link
> response header which basically tells the client that the 200 response
> doesn't mean what it says in RFC 2616, but instead what it says in LDP
> 1.0.
> 
> The correct way to do this is to simply reuse the definition in 2616
> so that the client knows nothing about the state of server after a
> DELETE has completed. I'm not familiar with the use case that requires
> those post conditions on DELETE, but from experience I can't imagine
> why a client would need to depend on this specific behaviour. Let me
> be clear though, my concern is *only* with the interface between
> client and server, not with server behaviour. If you want to define
> that LDP servers have to behave in a certain way, go nuts. But as soon
> as that information leaks into the interface, you've crossed a line,
> leaking implementation details so that the client is coupled not to
> the interface, but the implementation.
> 
> The same problem with DELETE exists elsewhere in section 4 too,
> including with PUT, though the definition seems close enough to 2616
> that I'm not sure why it's being redefined.
> 
> So in addition to those concerns about section 4, I'm also concerned
> with the requirements on client implementations and don't understand
> why they're necessary.
> 
> Some seem purely superfluous, such as 4.3.5, as it's part and parcel
> of the RDF model that resources can have multiple types (not to
> mention the open world assumption). The same goes for 4.3.6. 4.5.2
> falls under this category too because that behaviour is just one
> possible path through HTTP's conflict detection mechanism.
> 
> 4.5.3 and 4.5.4 seem more like BCPs that anything needing to be
> conformance criteria.
> 
> 4.5.5 just seems like a badly phrased constraint on server
> implementation that has nothing to do with a client.
> 
> 4.11.3.3 says that a client shouldn't invoke GET, really? Are you
> concerned about DoS issues like the W3C's DTD problem?
> http://www.w3.org/blog/systeam/2008/02/08/w3c_s_excessive_dtd_traffic/
> There's no reason to make this a criterion of correct client behaviour
> AFAICT
> 
> 4.11.3.4 also seems like it's part and parcel with the RDF model
> 
> In short, I think section 4 needs to be completely rewritten so that
> it;
> 
> - contains no client conformance criteria
> - contains no interface conformance criteria
> 
> In addition, the mandatory Link header should be removed so that
> clients won't be tempted to treat server behaviour implementation
> conformance criteria as interface conformance criteria; all LDP
> servers would be indistinguishable from Web servers.
> 
> Thanks.


Working Group Resolution (LC-2812):
Thank you for your feedback Mark.  

While we didn't go as far as rewriting section 4 entirely, we've modified
it to ensure that the specification doesn't seem to be redefining HTTP
which was never the intent.

http://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#conformance clarifies
the overall relationship between LDP and HTTP; 4.6.1 was removed entirely
as a result.

http://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#base-specs and
http://dvcs.w3.org/hg/ldpwg/raw-file/default/ldp.html#ldpclient were added
to clarify consequences of base specs and how LDP clients differ from HTTP
clients.

4.11 (at risk) was removed entirely.


----

Received on Monday, 18 November 2013 23:55:41 UTC