This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I spent a lot of time trying to understand things like 1) Why it wasn't ridiculous to say sml:ref="true" followed by sml:nilref="true"; 2) Why it made sense to define acyclic, targetType, etc. on a type that did not have an sml:ref attribute. After much puzzling (and questions to John) I believe the reason is because it can be useful to define some things in the model definition documents while leaving some decisions to the instance document author. For example: 1) The definition document might say that a particular type is an sml reference but the instance document author may decide to not to define it as a reference; 2) The definition document author might want to add constraints while leaving the decision about whether to use an sml reference up to the instance document author. I believe it would be helpful to readers if there were a non-normatve note (or two) that explained this.
resolution (6/5/08 conf call): mark needsAgreement
Proposal 1 (addresses part 1 of this issue re: sml:nilref attribute): Add this non-normative statement to the last paragraph of section 4.1.2 between the current first and second (last) sentences: For example, sml:nilref may be useful in the case where the complex type defines sml:ref="true" and an instance document author creating an element with that type does not choose to include a reference. Proposal 2 (addresses part 2 of this issue re: constraint attributes): Add one or more non-normative sentences at the end of section 5.1.3 that make these points: sml:ref can be defined either on a ComplexType or in the element declaration. sml:acyclic can be defined only on a ComplexType the sml:targetXXX attributes can be defined only on element declarations this is the reason that an element that is not an sml reference could be defined with one of the constraints on sml references this is valuable because the decision about whether to include a constraint and the decision about whether to make the element an sml reference can be made independently - some choices made by the schema author, other choices made by the instance document author
Resolution 6/19: Fix per proposal 1 in Comment #2. Fix per proposal 2 in Comment #2, bullets 4 and 5 only. No needsReview necessary.
Fixed as per Comment #3 Marked as needsReview as the changes in Proposal 1 might read better is the non-normative note is either mover to the end of the paragraph or the entire paragraph is incorporated into the note. Alternatively, the last sentence could be reworded. Proposal 1: http://dev.w3.org/cvsweb/~checkout~/2007/xml/sml/build/sml.html?content-type=text/html;%20charset=utf-8#Null_Reference Proposal 2: http://dev.w3.org/cvsweb/~checkout~/2007/xml/sml/build/sml.html?content-type=text/html;%20charset=utf-8#constraints_summary
f2f consensus review of comment 4 proposal 1: wg ignored the fact that no diff was given, grudgingly, however believes the text should be changed to: It is a consequence of the preceding that this specification assigns no meaning to the sml:nilref attribute when it is used on an element that is not an SML reference. Model validators MAY choose to warn their invokers should they detect this condition in a document. Note: sml:nilref may be useful in the case where the schema author defines a complex type specifying sml:ref with a fixed value of "true", but the instance author wants to signal the absence of a target. proposal 2: wg ignored the fact that no diff was given, grudgingly, however it prefers the following The constraints described above can be useful even on element declarations whose instances are not necessarily SML references, because the decision about whether to include a constraint and the decision about whether to make the element an SML reference can be made independently - some choices made by the schema author, other choices made by the instance document author.
Fixed as per changes in Comment #5
The following sentence is now repeated before and after the Note in SML 4.1.2, one of them (probably the second copy) should be removed. Model validators MAY choose to warn their invokers should they detect this condition in a document.
The fix requested in comment #7 was made as part of another bug fix since I noticed the repetition when editing that section.