Re: Proposal: normative changes for profiles

> types. The key thing seems to be 'as long as any constraints are 
obeyed'.

Actually (in terms of intent of the text from the Submission), the key 
thing was that those constraints (should, since it was focused on what we 
now call chocolate servers) be Minimal.

> 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 ?

It could apply (I dearly want to just say 'yes', but I see complications 
that lead to a more nuanced response).

If I read it very literally, it's tautological and therefore of little 
interest; I'd rather delete tautological statements than distract people 
with them, generally.

To make it interesting (non-tautological), I need to make those 
constraints visible to clients for introspection; that in turn shifts the 
issue to can the constraint language(s) cover ALL that an implementation 
might constrain.  I have yet to see even one that truly does; we usually 
just wave our hands after a certain point and fall back to natural 
language, whose intent is not yet available for strictly programmatic 
consumption.  We routinely take certain cases off the top (server limit of 
4K on a URL, or 1MB on an input representation) and say those don't 
violate MUSTs, which is a practical concession to annoyingly complex 
reality.

I had trouble quickly coming up with a substantive MUST statement in 
either direction; MUST-accept needs a "except for constraints not 
expressible via machine-readable constraint languages" disclaimer. 
MUST-reject (those that fall outside the constraints) prevents them from 
using Postel's Law, which I find very friendly as an end user.  Maybe you 
can do better.


Best Regards, John

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