Re: LDP feedback ( LC-2812)

Hi Mark,

We haven't received any response to the email below. We'd appreciate an 
indication of your acceptance of the WG response to your comment. If we 
don't hear back from you we will assume you're ok with it.

Thanks.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group


Arnaud Le Hors/Cupertino/IBM@IBMUS wrote on 11/18/2013 03:55:39 PM:

> From: Arnaud Le Hors/Cupertino/IBM@IBMUS
> To: Mark Baker <distobj@acm.org>, 
> Cc: public-ldp-comments@w3.org
> Date: 11/18/2013 03:55 PM
> Subject: 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.
> 
> 
> ----
> 
> 
>