Re: Proposal: normative changes for profiles

On 24 Sep 2013, at 19:50, John Arwe <johnarwe@us.ibm.com> wrote:

> The 3 editors took a quick pass through the spec, looking at existing conditionals (may, should) to see where they might become MUSTs etc on a vanilla-class server. 
> This is the set for which we all independently came to the same conclusion for both profiles.  The existing text and per-profile proposed value is listed below.  As with the "change to informative" proposal, since all 3 editors agreed taking independent passes (indicating that these may be non-controversial) I'm making it a single proposal.  In most cases where the chocolate constraint == today's (which is the vast majority), it's just a matter of keeping chocolate aligned with the existing base of WG decisions.
> 
> 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 LDPR servers SHOULD enable simple creation and modification of LDPRs. 
> vanilla: MUST 
> chocolate: SHOULD 
> This changes clause 1 of  4.2.9 only. 

[[
4.2.9 LDPR servers should enable simple creation and modification of LDPRs. It is common for LDP 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.
]]

so I am ok for vanilla MUST.
But I don't think it makes sense to say chocolate SHOULD, because there is no way the client can tell when it is confronted with one server or the other. 
Instead one should write out something like

Unless an LDPC contains a ldp:{restriction_vocab} relation an LDPC MUST allow the creation of any type of resource.
Then a client can know what to expect.


> 
> 4.3.3 LDPR servers SHOULD provide a text/turtle representation of the requested LDPR [TURTLE]. 
> vanilla: MUST 
> chocolate: MUST 
> 
> 4.5.6 LDPR servers MAY choose to allow the creation of new resources using HTTP PUT. 
> vanilla: MUST 
> chocolate: MAY 

Again there need to be a way for a client to tell wether he is confronted to an vanilla or a chocolate 
server here.

I can see the advantage of a PUT for creation: a great way to create a number of sub-containers in one go,
but it does mean that in that case one has to assume that any iContainers created along the way ( 
iContainers always end in a "/" ) have no restrictions imposed on them.

Perhaps an error response containing the reson for why a resource cannot be created by pointing to a restriction
would be the way around this.

> 
> 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. 
> vanilla: MUST 
> chocolate: SHOULD 

This should be put in terms of making the restrictions explicit. Then we have a MUST for vanilla and chocolate.
We just need to specify how a client can know of the restriction.


> 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. 
> vanilla: MUST 
> chocolate: SHOULD 

same as above

> 
> 4.8.3 LDPR servers SHOULD NOT allow clients to create new resources using PATCH. POST (to an LDPC) and/or PUT should be used as the standard way to create new LDPRs. 
> vanilla: MUST 
> chocolate: MAY 
> The replacement of Should Not was driven by the consideration: it would look strange to see us Must-ing it in one case (5789 explicitly mentions Create, so Must-ing it aligns with the PUT feedback from TimBL) and then Should Not-ing it in the other. 

I think it would be good to come up with some interesting examples to help us tune our intutions.


> 
> 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 
> 
> 5.8.1 LDPC servers are RECOMMENDED to support HTTP PATCH as the preferred method for updating LDPC non-membership properties. 
> vanilla: MUST 
> chocolate: SHOULD 
> 

why SHOULD for chocolate?

> 
> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario 
> 

Social Web Architect
http://bblfish.net/