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 <[email protected]> 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 > > [email protected] (Ian Green1/UK/IBM@IBMGB) > Chief Software Architect, Requirements Definition and Management > IBM Rational > > > _______________________________________________ > Oslc-Core mailing list > [email protected] > http://open-services.net/mailman/listinfo/oslc-core_open-services.net >
