Re: Proposal: normative changes for profiles - 4.5.7 thread

hello John, 

You say should is quite common and that a processor of a create request (say) should be liberal about what is accepted. I don't necessarily disagree, but there are plenty of scenarios too where the server should be less liberal. Infact, liberal capture could be one of the constraints published. So, I still don't think it is a SHOULD ... if anything it is a maybe ...

I agree that we want the vanilla case to be unconstrained. 
But, I might restate that as: A vanilla server is just a chocolate server with zero constraints. 

Roger


On 2 Oct 2013, at 14:13, John Arwe wrote:

> 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 

> in section 4.5.7 I have concerns with SHOULD for chocolate servers.   
> If the client doesn't satisfy the constraints, then I would expect 
> the update to fail. If the client doesn't have "knowledge of the 
> server-specific constraints" then it is even more likely to fail ...
> So, I don't know what SHOULD really means in this case. 

What IBM has found over several years of building chocolate servers is that it's advantageous to allow creates of "barely legal" (in an application sense) resources rather than failing create requests.  In many cases the application context is really: I need something to point at (the resource being created) from elsewhere.  In that sense, the resource creation request is not The End, it is A Means To The End.  Using our favorite bug-tracker example, maybe you allow create to succeed even if there is only a description, and then require an admin to update it in some way (perhaps assigning a target "component"/product/organization) before it's part of the normal process flow.  The "created but barely legal" state is treated as "needs attention" in some way. 

ITIL does this with Incidents; all you really need from the user is a description (server-managed properties like creator are likely added automatically).  Most organizations won't work on that until it has been looked at by a "level 1" group who assigns it to the most likely product support group. 

This language came from those kinds of experiences.  The weasel words in there are "detailed" and "server-specific" ... well, what's detailed/not.  If you're a bug tracker server and there's some common spec "everyone" uses for bugs, then there's going to be a different level of community understanding (perhaps) about what's "obvious from the spec" vs what's a product-implementation decision.  Certainly most devs I know have trouble with that distinction. 

Maybe the chocolate-should is better phrased as a best practice, not sure.
I am sure we want the vanilla case to be unconstrained... which might require removal of the weasel words too.



Best Regards, John

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