[oslc-core] Clarification on oslc:readOnly
Dave
snoopdave at gmail.com
Mon Oct 11 08:44:22 EDT 2010
I think those are reasonable clarifications, and I believe they should
be added to the spec with the exception of the breaking change (i.e.
making "oslc:readOnly be a Resource|Reference, with values
http://open-services/ns/core#true and false").
- Dave
On Fri, Oct 8, 2010 at 5:37 AM, Ian Green1 <ian.green at uk.ibm.com> wrote:
>
> The description of this property is unclear. It currently reads
>
> true if property is read-only. If not set or false, then property is not
> read-write.
>
> How about:
> true if the property is read-only. If not set, or false, the
> property is writable.
>
> Do we additionally want some explanation of read-only? Here is an example,
> but perhaps the use of SHOULD below is too strong -
> Providers SHOULD declare a property read-only when changes to the
> value of that property will not be accepted on PUT. Consumers should
> note that the converse does not apply: Providers MAY reject a change
> to the value of a writable property.
>
> I'd suggest that if oslc:readOnly is of type xsd:boolean, we adopt the
> lexical space defined by XSD (true, false, 0, 1).
>
> (If we could tolerate a breaking change at this stage, I'd suggest that
> oslc:readOnly be a Resource|Reference, with values
> http://open-services/ns/core#true and false. )
>
>
> best wishes,
> -ian
>
> ian.green at uk.ibm.com (Ian Green1/UK/IBM at IBMGB)
> Chief Software Architect, Requirements Definition and Management
> IBM Rational
>
>
> _______________________________________________
> Oslc-Core mailing list
> Oslc-Core at open-services.net
> http://open-services.net/mailman/listinfo/oslc-core_open-services.net
>
More information about the Oslc-Core
mailing list