This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The component model diagram in appendix I of http://www.w3.org/TR/2005/WD- xmlschema11-1-20050224/ needs some corrections, including but not limited to. * Should be an arc from the schema component to identity constraints * substitution group affiliation should be a circular arc * facets are components; should be arcs * don't understand why the arc from the schema component to complex type definitions is dotted Editorial concerning Part 1 Schema Components Diagram Transition history raised on 25 Mar 2005 by Mary Holstege (http://lists.w3.org/Archives/Public/www- xml-schema-comments/2005JanMar/0077.html)
On the call of 23 February 2007 the Working agreed to class this issue as editorial.
For some readers of the spec, I think it would also be useful to identify the graphical notation used, and to explain what the different kinds of arrows mean, and at least in a general way what the diagram is intended to convey. (As one data point: I know one reader who reports that he recognizes the diagram to be UML, but says he has not yet succeeded in understanding it. From time to time he turns to one or the other of the various UML books he has bought to try to bring himself to learn UML, with the intention of looking up what the arrows mean, but he reports difficulty looking up the meaning of the diagram, since in order to read the rules for understanding the UML diagram he must apparently first know which of the nine classes of UML diagram this is. I point out that this is the kind of UML most frequently encountered, and he agrees but points out that 'the kind you see most frequently' is not a label on any of the sections in any of his books. If the spec expects him as a reader, he says, then the spec would do better not to assume quite so much background in UML.) I'd propose some sample text to say what notation the diagram is in and the essentials of what it conveys, but I've never understood the diagram myself, so I don't know what the paragraph would say.
The diagram is clearly intended to be a "UML Class Diagram", for which you can find a tutorial at http://www.sparxsystems.com.au/resources/uml2_tutorial/uml2_classdiagram.html (The actual specification can be reached via www.uml.org, but the PDF file crashes Firefox on my machine). I think the dashed line has been made dashed purely because it has a crossover with solid lines; there are no semantics intended. All the arrows on the diagram are shown as "aggregation" relationships. I think many UML users tend to show all 1-to-many associations as aggregation relationships simply because the notation is more graphic; in fact I have never understood the distinction UML tries to make between aggregations and more general associations; it seems to be entirely subjective. One could certainly question the analysis: for example element-declaration should not have separate relationships with simple-type-definition and complex-type-definition, it should have a single relationship with type-definition, which should exist as a generalisation of simple-type and complex-type. This one is clearly a many-to-many relationship, and although I think it's legal in UML, I personally find the notion of modelling a many-to-many relationship as an aggregation pretty weird.
The old components diagram has now been replaced by two diagrams drawn by David Ezell. Some, I think, of the issues raised in this bug report and the comments on it have been addressed in the new diagrams; some I have attempted to address in the introductory prose. The new diagrams are visible in the new status-quo documents at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.html http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.diff-1.0.html http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.diff-wd.html (all member-only links) Some concerns appear not to have been addressed at all yet; we may want to do yet another revision of the diagrams. But in the belief that the new diagrams are an improvement on the old one, and noting that this is classified as an editorial issue, my current plan is to include the new diagrams in the next public working draft. If members of the WG or IG wish to provide newer and better diagrams, please feel free to do so without delay. Mary, I'll leave it to you whether to mark this issue resolved or leave it open.
I made the following changes to the diagram, approved by Mary, so this item becomes "decided". > > No annotations anywhere (I think this is probably OK, but > we should say something in the verbiage about it) [DE] added > > No names for named components anywhere: should be > a property, no? [DE] already fixed. > > Open Content? [DE] shown as an association (property records seem a bridge too far). > > Schema: > missing link to identity constraint definitions [DE] already fixed. > > Simple type definition: > facets are components, not properties > Facet component has properties fixed and value [DE] done. > hmmm... but the value property for the assertion facet is an > assertion, > so maybe you need a link as well? [DE] decided not to show the link from facet to assertion, but did add an Assertion component. > item type definition, where? > member type definitions, where? > primitive type definition, where? [DE] added as properties. > context, where? [DE] already done. > > Complex type definition: > base type definition, where? > context, where? [DE] already done. > > Attribute group definition > missing from top part of diagram entirely > (attribute uses, attribute wildcard) [DE] already done. > > Model group definition, likewise [DE] already done. > > Element Declaration > points to a CTA, which should be a Type Table > Type Table needs links to default type definition and to > alteratives > alternatives are Type Alternative component with property > test > and link to > > type definition [DE] opted to keep consistent with property record treatment and make a property. > scope, where? [DE] ditto. > substitution group affiliations should be link to components, not > a > property [DE] done. > > Identity Constraint Definition > referenced key should be link to component, not a property [DE] already done. > > Assertions > missing test property [DE] added.
On 20 May, after discussion, the WG decided to suppress this diagram at least for now, possibly restoring it in the course of time. The change agreed on then has now been integrated into the status quo document, so I'm marking this bug as resolved. Mary, if as originator of the issue you would check to see that the change has been implemented correctly and then either close or reopen the issue to signal assent or dissent, it would be helpful. Thanks.