Hi Yves, all
IMHO, the intent was to have only one comment per annotation. IMHO if both the value and the note were allowed to hold comment text at the same time this could pose display issues for implementers, we would need to set priority of value over note text or vice versa etc.
In case the TC agrees that the intent was to allow only one at the time. The fix is as follows.
OLD
- If the value attribute is present it contains the text of the comment, otherwise the ref attribute must be present and contains the id value (in URI format) of a <note> element that holds the comment.
NEW
- If the value attribute is present it contains the text of the comment. If and only if the value attribute is not present, the ref attribute must be present and contain the URI of a <note> element within the same enclosing <unit> element that holds the comment.
Please note that the above change also constrains the comment annotations to use as comment text only notes that are on the same unit. That Yves had not commented on, but it only brings up the constraint that we already have on the ref attribute.
[
- When used in a comment annotation, the value is referring to a <note> element within the same enclosing <unit>.
]
The above is what I suggest and what I will consider approved by the TC unless I hear dissent by Monday, March 17, end of day PDT.
Cheers
dF
=======================
LRC | CNGL | LT-Web | CSIS
University of Limerick, Ireland
telephone: +353-6120-2781
cellphone: +353-86-0222-158
facsimile: +353-6120-2734