OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

wsrm message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Suggestions to improve wordings of features and properties

Recently, the editors have done a great job of removing ambiguities and 
improving readability of the spec.

There was a change in the definition of a Property in B.3.3 which 
prompted some discussion amongst the editors and me. The new definition 
does not specify the scope of the property and where it can occur. In 
addition, features and properties have been defined twice. I have the 
following suggestions to fix this (thanks to Tom/Mark/Doug for the 

1) In section B.1 (Introduction), there is a bullet list consisting of 
feature (and its definition), property (and its definition) and 
compositor (and its definition). I would like to propose that we keep 
the bullet list, but remove the definitions and replace it with forward 
references to the appropriate sections where the definition occurs)
  * feature <reference-to-B.3.2>
  * property <reference-to-B.3.3>
  * compositor <reference-to-B.3.1>

This would mean that the definition will occur only once in the spec.

2) At the end of the 2nd sentence in B.3.3 add:
"A property can occur only as a child of a compositor."

The complete paragraph now will be:
"A property is identified by a QName. A property is an assertion or 
constraint on a specific RM capability and its value(s). A property can 
occur only as a child of a compositor."

This was missing in the text, but it was the original intent (this 
sentence also occurs in the definition of a feature). The compositor 
section already states that compositors are used to compose features and 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]