|
[
Permalink
| « Hide
]
Ryan McVeigh added a comment - 26/Feb/09 03:30 PM
A use case I can see is to indicate that a property must be populated at create time, but may not be subsequently modified. Or perhaps a property may only be populated by a pre-defined choice, but not modified.
As described on p.38, a "read-only" property is a system property that is maintained or calculated by the repository. It can not be updated by application using the updateProperties() method.
For a non-read-only property, "required" means the property can not be in a "value not set" state. It MUST have a value either provided by application or set by default. For a read-only (i.e. system) property, "required" means a value MUST be returned when the property is requested. "Not required" means the system property may be in a "value not set" state. This definition is a bit overloaded. One is "read-only" means system property. The other is "required" has two different meaning, depending on the updatability attribute, which can cause confusion. If we want to avoid overloading, we can either add another attribute, or remove some modeling granularity. It all boils to to whether "required" is seen from the writer's side (a value is required when the document is created/updated), or from the reader's side (the value will always been set).
We should clarify required is from the writer's point of view. Also, the spec should be updated to say that repositories should not have properties that are required + readonly and that if such properties exist on an object, then updates will fail
|
|||||||||||||||||||||||||||||||||||||||
 |
|
Bug
Closed
Trivial
Property Definitions: A property definition should not ever say READONLY + REQUIRED