[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