Re: Re: Comments on LDP TR http://www.w3.org/TR/2013/WD-ldp-20130730/ ( LC-2835)

 Dear Tim Berners-Lee ,

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 22 November
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/34BE20B3-86E3-434F-B454-B004E9A338F0@w3.org
 2. http://www.w3.org/TR/ldp/


=====

Your comment on :
> 4.9.1 Servers must support the OPTIONS method.  Why?   Should there be 
> a basic level
> of functionality which any LDPR allows and which does not require
> OPTIONS polling?
> 
> OPTIONS is expensive: another round trip.
> 
> Always avoid an extra round trip if you can.
> We need this system to move really fast.
> Round trips show up as user interface sluggishness, user task
> inefficiency, and lost/bored users.
> 
> Note that OPTIONs is resource-specific. (Unless you use some sort of
> wildcard extension
> or a POWDER label say).    You have to do it for every fresh URI you
> find.
> 
> The Linked Data operation is a GET.  Is the basic operation for an
> LDP-capable client always OPTIONS, GET,  or GET, OPTIONS? 
> 
> Maybe key headers can be put into the HEAD and GET response.
> 
> Maybe the class of resource announced with Link: rel=type
> can have a URI which can be looked up itself and cached.
> and will give the set of features in a standard way.
> 
> Suggest define  a core LDP protocol which does NOT use OPTIONS, by
> assuming that 
> the core functionality is enough for clients to do what they need.
> Clients needing extensions maybe can use OPTIONS.  But maybe POWDERR
> should be preferred.


Working Group Resolution (LC-2835):
OPTIONS is not required to achieve this. It could be used in cases when a
client wants a low-cost means to learn more about the resource identified
by the URI if it hasn't already done a GET. If it has done a GET and kept
the header information, there is no need to use OPTIONS.

----

Received on Saturday, 16 November 2013 01:03:04 UTC