Re: <accept>none</accept>

[James M Snell <jasnell@xxxxxxxxx>]

I understand the subtlety issue that Bill and Aristotle are concerned
about but I think the clunkiness of the 'none' value is error prone
(e.g. <app:accept>none, entry</app:accept>) and unnecessary.  That said,
I could live with either approach.

- James

Thomas Broyer wrote:
> 
> 2006/11/16, A. Pagaltzis:
>>
>> The defaultifying suggestions are neat and have a certain
>> elegance, but they strike me as overly subtle.
>>
>> Using a present but empty accept element is consistent way of
>> expressing that a collection is read-only, but then the absence
>> of an accept element becomes an issue: either it means the same
>> as an empty element, which is a simple rule but not very useful,
>> or it means something else than an empty element, which is
>> fragile.
>>
>> So while having an explicit value for "does not accept anything"
>> is clunky, I think it will be the better choice in this case.
> 
> I'd prefer having "no default" (i.e. absent app:accept == empty
> app:accept == nothing is accepted as POST == can't create*) than a
> clunky "none" value. With such a thing, you'd have to be prepared to
> handle cases like <app:accept>none, entry</app:accept>.
> 
> * note that "can't create" is not equivalent to read-only: existing
> members could still be editable and/or deleteable.
>