Re: Proposal: normative changes for profiles - replacement

+1 overall.
I'm a bit concerned about moving 4.2.9 to best practices.
I think something on those lines would be good in the spec.
We can discuss
All the best, Ashok
On 10/16/2013 10:27 AM, Steve Speicher wrote:
> +1 to all these proposals (hoping to break the ice)
>
> - Steve Speicher
>
>
> On Tue, Oct 15, 2013 at 2:43 PM, John Arwe <johnarwe@us.ibm.com <mailto:johnarwe@us.ibm.com>> wrote:
>
>     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:typepredicates, 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 <http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Internet+address&location=All+locations&searchFor=johnarwe>
>     Tivoli OSLC Lead - Show me the Scenario
>
>