Re: Proposal: normative changes for profiles - replacement

+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> wrote:

> Full replacement for LDP proposal *
> http://lists.w3.org/Archives/Public/public-ldp-wg/2013Sep/0067.html*<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<http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Internet+address&location=All+locations&searchFor=johnarwe>
> Tivoli OSLC Lead - Show me the Scenario
>
>