Re: Proposal: normative changes for profiles - 4.5.7 thread

> 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