Re: Proposal: normative changes for profiles

I have to say that Roger is onto something I've been wrestling with all 
along with regard to the spec and I like the phrase "providing constraints 
set by the server are met".

As I've been trying to explain, this seems to be a general condition that 
pretty much applies across the board and with regard to different kinds of 
constraints. We're now focusing on domain specific constraints governing 
the data but how is that really different from other constraints such as 
access control? Why is it that we take for granted that MUSTs in the spec 
are subject to having the right authorization but not to data validity 
constraints? Why do we have to treat these differently?

I'm not saying there isn't a good reason for this. I just don't know.

Best regards.
--
Arnaud  Le Hors - Software Standards Architect - IBM Software Group


Roger Menday <roger.menday@uk.fujitsu.com> wrote on 10/03/2013 04:23:18 
AM:

> From: Roger Menday <roger.menday@uk.fujitsu.com>
> To: John Arwe/Poughkeepsie/IBM@IBMUS, 
> Cc: Linked Data Platform WG <public-ldp-wg@w3.org>
> Date: 10/03/2013 04:24 AM
> Subject: Re: Proposal: normative changes for profiles
> 
> John, 
> 
> For the vanilla case I'm happy with the MUSTs and 'make creation 
> easy' thing. I think this is good. 
> 
> I question the chocolate case - there seems to be looser guarantees,
> which doesn't seem fair. e.g. I think that MUSTs are useful for both
> types. The key thing seems to be 'as long as any constraints are 
obeyed'.
> 
> As a suggestion, and just taking 4.2.9 as example, why not say 
> something like "providing constraints set by the server are met, 
> LDPR servers MUST enable creation and modification of LDPR's". Isn't
> this phrasing applicable to both the vanilla and chocolate cases ?
> 
> Roger
> 
> p.s. I'm just thinking out loud. I'll wait for on your steering 
otherwise ... 
> 
> On 2 Oct 2013, at 18:28, John Arwe wrote:
> 
> > But, I might restate that as: A vanilla server is just a chocolate 
> > server with zero constraints. 
> 
> I'm not clear if you are thinking out loud or making a different 
> proposal (either is fine). 
> 
> All I can say is: 
> - if you are making a concrete proposal, I'd suggest including the 
> new and old full text.  People seem to do better with a strawman. 
> - Assuming that the above corresponds to a proposal to completely 
> replace 4.5.7, I'd prefer to not entirely lose "make creation easy" 
> thought so I'd -0.5 such a proposal.  I am completely open to that 
> becoming a guideline as a way to keep it, if that's where WG consensus 
lands.
> 
> Broadly speaking, I agree with the sentiment you expressed, applied 
> to the limited context of 4.5.7.  It would need to be re-cast in 
> 2119 language of course. 
> 
> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario