This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
1. (minor editorial) In section 3.16.2.1: "2.4.2 otherwise (the grandparent element information item is <simpleContent>), the Simple Type Definition which is the {content type} of the Complex Type Definition corresponding to the great-grandparent <complexType> element information item." {content type} should be {content type}.{simple type definition}. 2. In 3.4.2.2, {content type}.{simple type definition} is "a simple type definition which restricts ... with a set of facet components ... as defined in Simple Type Restriction (Facets) (ยง3.16.6.4);" This doesn't specify what the values should be for properties of this simple type definition, other than {variety}, {primitive type definition}, and {facets}. In particular, it's not clear what the {context} should be for this simple type. Suggest to specify that the {context} is the complex type definition corresponding to the ancestor <complexType>. Or, even better, to specify values for all the properties of this simple type.
3. Another case where the {context} is not specified is when <simpleType> or <complexType> appear as a child under <alternative>. The containing Type Alternative component seems to be a good candidate for {context}.
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?
In the context of "2. In 3.4.2.2, {content type}.{simple type definition}" > It seems to me that ... the values of ... 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 I agree this is possible, but it may impose some interesting ordering. There are situations where we follow 3.x.2 rules to construct "things" (not yet components, as they could turn out to be bad), then we check 3.x.6 rules. What you suggest above seems to require that if 3.x.2 is not explicit about a value of a property, then we use "a/the" value that will pass tests in 3.x.6. I'm not confident that this is an established practice, and whether it's easy to understand/implement. What if there are more than 1 values that pass 3.x.6? > in other cases (e.g. {name}) they follow from the rules about how simple > type definitions get their names. In this particular case, the simple type definition does *not* correspond to any <xs:simpleType> element, so rules in 3.16.2 don't apply. This is similar to other cases where we *synthesize* a component (i.e. with no corresponding source in the schema document), e.g. for (mixed/extension) particles. > I agree that the nearest enclosing complex type is the natural choice. Agree that it should be the "nearest". > is it worth adding type table to this list for this situation? > Would it not be better just to use the enclosing element declaration? I thought I had a reason for favoring the Type Alternative over the element decl, but I can't remember it now.
A wording proposal intended to resolve this issue is at http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b11290.html (member-only link) for review and comment. It leaves to the WG the choice of element declaration or type alternative as the value of {context} when a type is declared within a type alternative.
RESOLUTION: accept the proposal, using alternative 'B' in each case.
The decision reported in comment 5 has now been implemented by integrating the change proposal of comment 4 into the status-quo document. Sandy, if you would close or reopen the issue to signal your assent or dissent, it would be helpful. Thanks.