This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Concepts ------- 1) Report AND Assert: Having both assert and report in the syntax seems (and has always seemed) redundant and unclean. Both can be expressed in terms of the other so only one is necessary. Having them both and calling them assert and report are the last vestige of Schematron, and considering that the current proposal in many ways differ from Schematron (not least the fact that we associate CC to types rather than elements) makes the Schematron-like syntax confusing and uncalled for. 2) Why should assert and report be elements? Getting rid of the two elements would allow us to get rid of the element itself, and just rely on a single attribute (e.g., test) to be placed anywhere, but most appropriately in the complexType element itself. 3) CC and extensions: CC always provide restrictions to the expressed content model. It is my impression that so far derivation by restriction and derivation by extension have been kept carefully separated, and features of one have never allowed when using the other (AFAIK I cannot restrict an optional behavior when extending a type). Now CC allow me to mix the two approaches: I can practically (if not theoretically) restrict a type with CC while extending it with the content model expression. I have nothing per se against this, but it is a strong deviation with the past. Do we all like it?
> 1) Report AND Assert I thought the WG explicitly decided to have both elements, but when I went back and check meeting minutes [1], I didn't find that resolution. (Or one can assume that the adoption of the proposal in Aug. [2] implicitly made that decision.) [1] (member-only) http://www.w3.org/XML/Group/2006/04/xml-schema-ftf-minutes [2] (member-only) http://www.w3.org/XML/Group/2006/08/xml-schema-ftf-minutes > 2) Why should assert and report be elements? ... a single > attribute (e.g., test) ... most appropriately in the > complexType element itself. That would only allow one assertion per each complex type. > 3) ... it is a strong deviation with the past. Do we all like it? There is (at least) one precedence. When you extend a complex type with an attribute wildcard, you can add a new attribute that's allowed by the wildcard. This is effectively a restriction. I was a little uncomfortable by this deviation too, but thought it was OK: a) I couldn't think of a better way to deal with it. Ignoring assertions from base is certainly wrong; not allowing new assertions in extension? b) It doesn't seem to be harmful. We can imagine systems that depends on the semantics of restriction (accepts less). Not sure whether anyone depends on the extension semantics of a newly introduced property.
This issue has been addressed in a wording proposal adopted at the New Orleans face to face meeting on 31 January of this year; final amendments to the wording were approved on today's WG teleconference. Accordingly, I'm marking this issue as closed. The quick summary: the 'report' element has been deleted, as suggested in point 1). The 'assert' element, however, remains an element, since the WG regarded the ability to have several distinct assertions, with distinct annotations and identities, on the same type. So point 2) was not adopted. On point 3), the views of the WG were divided, so the answer to your rhetorical question is: no, not everyone likes the ability to add assertions in the course of defining an extension. But those of that mind failed to persuade the rest of the WG. One reason given for retaining the status quo was that there are already cases with similar effect: by adding an attribute declaration whose name matches a pre-existing wildcard, an extension can effectively restrict a complex type (since attributes with that name must now conform to the specified type), even in the course of an extension step. Most persuasive for some in the WG, perhaps, was the observation that one might want to add elements X, Y, and Z to a complex type, and at the same time make an assertion about their interrelations. It would seem awkward to require two derivation steps to do such a natural thing. Allowing such an extension step also seems to require allowing the extension step to add X, Y, and Z, and at the same time restrict the interrelation of children A, B, and C. Even if this seems odd, it was felt that this is an acceptable price for being able to make assertions about X, Y, and Z at the time they are added to the content model. Since one of the three points you make was accepted, and two were not accepted, it's not clear whether this issue should be marked FIXED or WONTFIX or INVALID. Since two out of three proposals were declined, on the grounds that there is not really a problem, I guess INVALID is arithmetically more appropriate. Accordingly, I am marking the issue RESOLVED / INVALID. As originator of the issue, Fabio, you are asked to signal whether you are content with the consideration and disposition of the comment, by changing the status from RESOLVED to CLOSED, if you agree with the disposition (or are willing to acquiesce in it), or by changing it to REOPENED if you wish to signal a strong dissent and a formal appeal from the decision of the WG. If we don't hear from you in a couple of weeks, we'll assume you are content.