Re: Proposal: normative changes for profiles

On 15 Oct 2013, at 15:53, John Arwe <johnarwe@us.ibm.com> wrote:

> Henry, thanks for your careful input. 
> 
> Some of the issues you raise were outside the intended scope of this proposal (remembering that most of that spec pass by editors was done a month ago on the last day of the F2F) ... like how a client "susses" out which flavor server it is interacting with.  We had talked about using the existence of constraints for this, just no one made a formal proposal on that yet. 
> 
> I am going to take another pass at this proposal based on the comments/discussions to date; should have it out later today for scrutiny.  In the mean time, responses to a few points below. 
> 
> 
> 
> > 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 ...
> > 
> > I think it would be good to come up with some interesting examples 
> > to help us tune our intutions. 
> 
> This part surprises me.  The examples would be the same as for PUT-create; semantically the same intent, just a different syntax.  5789 does explicitly allow Patch to be used for creation, as is noted somewhere in the existing text/threads.  Or am I missing your point? 

Ah ok, I was thinking you'd PATCH an LDPC to add new members there, and somehow this would create new resources.
You are just thinking of PATCHing like PUT which is different... 

> 
> 
> 
> > 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? 
> 
> The general approach the editors took during that pass was minimal change.  Unless we had some compelling reason, we were biased toward keeping the constraints unchanged for chocolate (recommended == should) as they were, and (as TimBL suggested) tightening constraints on vanilla. 
> I don't know that the net result would be any different if we did a new pass today, although the reason would be different.  Until we have an agreed-upon patch format, MUSTing it does not improve interop; and progress on a patch format seems stalled.  Given the criticisms commenters had about inlining around incompleteness, the same should be true for Patch; it's just in the latter case that most/all (including myself, personally) are more attached to Patch even with the gaping interop hole. 
> 
> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario 
> 
> 

Social Web Architect
http://bblfish.net/