RE: Suggestion to change {safety} to {safe}

I was thinking {explicitly safe} - similar idea. That lets the Woden code have "isExplicitlySafe", which would suggest that the opposite is "not explicitly safe", which is exactly what we want, because it allows "implicitly safe".
 
Tony

________________________________

From: www-ws-desc-request@w3.org on behalf of Roberto Chinnici
Sent: Thu 01-Jun-06 3:34
To: Jacek Kopecky
Cc: John Kaputin (gmail); www-ws-desc@w3.org; woden-dev@ws.apache.org
Subject: Re: Suggestion to change {safety} to {safe}




How about {safety asserted}?

Thanks,
Roberto

Jacek Kopecky wrote:
> Hi John,
>
> the difference between {safety} and {required} is that for the latter,
> false is not true, whereas for {safety} false is unclaimed. An operation
> that doesn't claim to be safe can still be.
>
> Therefore {safe} could be misleading. However, I'm not sure that
> {safety} is non-misleading enough here. 8-)
>
> Jacek
>
> On Wed, 2006-05-24 at 22:43 +0100, John Kaputin (gmail) wrote:
>> A bit late in the day (sorry), but I'd like to suggest renaming the
>> extension property {safety} to {safe} to better describe one of the
>> binary states (safe vs unsafe) of this property, which in turn will
>> map neatly to a boolean API method like isSafe(). It also reflects the
>> discussion of this property in the spec which talks about operations
>> being 'safe' or 'unsafe'.  getSafety() is cumbersome and isSafety()
>> doesn't sound quite right.
>>
>> As an example, the {required} boolean property describes a binary
>> state (required vs not required) that maps neatly to the boolean
>> method isRequired().
>>
>> Our options in Woden are to just adopt the isXXX() convention for a
>> boolean property {XXX} and not worry about how it sounds or diverge
>> from the exact property-to-method naming convention we have been using
>> and construct a more suitable boolean method name (i.e. for the
>> boolean properties {http cookies} and {http location ignore uncited}).
>>
>> regards,
>> John Kaputin.