Re: Proposal: normative changes for profiles - replacement

Full replacement for LDP proposal 
http://lists.w3.org/Archives/Public/public-ldp-wg/2013Sep/0067.html that 
enumerated constraints different for vanilla versus chocolate servers. 
This revised proposal reduces the points of divergence down to PUT/PATCH 
support, which are complicated enough due to some conflicting goals that 
I'll just remove them and treat as a completely separate proposal.  I.e. 
from the point of view of ONLY what remains here, which is the vast 
majority of the original differences, there is NO difference in the 
proposed text between what we today call vanilla and chocolate servers. 
Cue: bad analogies about swirls, spumoni, neopolitan, table wines, etc.

If you object (-1) to any of the listed sections being changed, please 
provide the specific list in your response and we'll simply treat those 
separately. 

If you do not object (+0 or +1), either save it for a WG decision on one 
of the next meetings or (if you're sending regrets for that meeting) email 

to get your vote in early.


4.2.9 LDP servers SHOULD enable simple creation and modification of LDPRs. 
 It is common for LDPR servers to put restrictions on representations – 
for example, the range of rdf:type predicates, datatypes of the objects of 
predicates, and the number of occurrences of predicates in an LDPR, but 
servers SHOULD minimize those restrictions.  Enforcement of more complex 
constraints will greatly restrict the set of clients that can modify 
resources. For some server applications, excessive constraints on 
modification of resources may be required.

Move entire constraint to Best Practices.  (Note: original proposal only 
hit 4.2.9 clause 1).



4.3.3 LDPR servers SHOULD provide a text/turtle representation of the 
requested LDPR [TURTLE]. 
vanilla: MUST
chocolate: MUST



4.5.7 LDPR servers SHOULD allow clients to update resources without 
requiring detailed knowledge of server-specific constraints.   This is a 
consequence of the requirement to enable simple creation and modification 
of LPDRs. 

Replace with the text below:

NOTE on new text: putting this in General requirements, could replace 
4.2.9, or if less confusing can call it 4.2.13 until we do a mass-renumber

NOTE on new text: referring to POWDER *only* for the link relation 
definition, NOTHING else from POWDER is required.

4.2.13 LDP servers MUST publish any constraints on clients’ ability to 
create or update LDPRs, by adding a Link header with rel=”describedby” 
[[!POWDER-DR]] to all responses to requests which fail due to violation of 
those constraints.  For example, a server that refuses resource creation 
requests via HTTP PUT, POST, or PATCH would return this Link header on its 
4xx responses to such requests.
The same Link header MAY be provided on other responses.  LDP neither 
defines nor constrains the representation of the Link's target resource; 
as stated in [[POWDER-DR]], the target might (or might not) be a POWDER 
document.  Natural language constraint documents are therefore permitted, 
although machine-readable ones facilitate better client interactions.

Add boilerplate at the beginning of the sections (PUT, PATCH, etc.) ala: 
Any constraints on create or update are subject to 4.2.13 [link], which 
imposes requirements on server responses to those requests.

Add Best Practice: minimize number of server-specific constraints. Perhaps 
talk about Ashok's 3 classes of constraint.




4.8.2 LDPR servers SHOULD allow clients to update resources without 
requiring detailed knowledge of server-specific constraints.   This is a 
consequence of the requirement to enable simple creation and modification 
of LPDRs. 
Delete – covered by 4.2.13



4.10.2.1 LDPR servers SHOULD allow clients to retrieve large LDPRs in 
pages. 
No change ...here for context with the following sentence, below.

4.10.2.1 In responses to GET requests with an LDPR as the Request-URI, 
LDPR servers that support paging SHOULD provide an HTTP Link header whose 
target URI is the first page resource, and whose link relation type is 
first [RFC5988].
vanilla: MUST
chocolate: MUST



Best Regards, John

Voice US 845-435-9470  BluePages
Tivoli OSLC Lead - Show me the Scenario