- From: <bugzilla@jessica.w3.org>
- Date: Wed, 02 Mar 2011 17:15:48 +0000
- To: www-xml-schema-comments@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=11290 --- Comment #2 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> 2011-03-02 17:15:47 UTC --- It seems to me that as well as {facets}, which is specified explicitly, it is not only the values of {variety} and {primitive type definition} but also the values of {annotations}, {name}, {target namespace}, {final}, {base type definition}, {fundamental facets}, {variety}, {item type definition}, and {member type definitions} which follow from the rules of the spec. In some cases, they seem to me to follow from the statement that the type being described is a restriction of the other simple type identified (with characteristically convoluted syntax) in the first part of clause 1; in other cases (e.g. {name}) they follow from the rules about how simple type definitions get their names. (It's possible, of course, that we have managed to write so many special cases and exceptions into the rules elsewhere in the spec that they turn out not to apply in this case. If that is so, I think the right thing to do is to simplify and generalize the rules elsewhere in the spec so that they do apply, rather than adding one more special case provision here.) That would leave {context} to be specified. I agree that the nearest enclosing complex type is the natural choice. (At least, I think that means we're in agreement: "the ancestor <complexType>" is not guaranteed unique, and it's possible SG means one of them other than the nearest ancestor.) The {context} property is currently defined as having an Attribute Declaration, an Element Declaration, a Complex Type Definition or a Simple Type Definition as its value; is it worth adding type table to this list for this situation? Would it not be better just to use the enclosing element declaration? -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 2 March 2011 17:15:50 UTC