This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
XSD 1.1 Part 1, 3.4.2.2, XML Mapping Summary for Complex Type Definition with simple content Schema Component, {content type}.{simple type definition} clause 2 has: <quote> (let SB be the simple type definition corresponding to the <simpleType> among the [children] of <restriction> if any, otherwise ·xs:anySimpleType·) a simple type definition which restricts SB with a set of facet components </quote> If I read this convoluted text correctly, it implies that constraining facets can apply to xs:anySimpleType. But we say very clearly elsewhere, notably in 3.16.1, that they don't: <quote> ·xs:anySimpleType· or ·xs:anyAtomicType· must not be named as the {base type definition} of any user-defined atomic simple type definitions: as they allow no constraining facets, this would be incoherent. </quote>
I agree that if the type FB is anySimpleType, the result of constructing a simple type component which restricts FB with a non-empty set of facets will be a component which violates the rule given in 3.16.1. This appears at first glance to be a case of the constraints on XML being changed to require less knowledge of the entire schema, and the XML mapping rules being changed to work for all valid schema documents (including some which used to fail the 'XML constraints' based on information not present in the XML). Some cases which used to fail (notionally) in the XML constraints, which the mapping rules didn't need to cater for, now fail (notionally) at the time when component constraints are checked. For some of these cases, we have added health warnings pointing out that the mapping rules are not guaranteed to produce legal components. I think that at the ftf meeting last month the WG was inclined not to add more health warnings than are already present, but if we decide to reverse that policy, we could add the following warning after clause 2 in the mapping rule: Note: if there is no simple type definition corresponding to the <simpleType> among the [children] of <restriction> (and if therefore S_B is xs:anySimpleType), and the set of facet components specified in the <restriction> elementis non-empty, the result will be a simple type definition component which fails to obey the constraints on simple type definitions, including for example clause 1.3 of Schema Component Constraint: Derivation Valid (Restriction, Simple). I am agnostic about the utility of adding such warnings; they are handy for those who have not yet unlearned the assumption that the mapping rules will always produce conforming components, but they do clutter the text a bit for those who have unlearned that expectation and who thus don't need the reminder. (Although, as here, it may be useful to have a pointer to at least one of the constraints that will be failed.) On balance, I am inclined to propose that we resolve this bug by adding the note given above.
I can see that there are cases where we prefer not to detect errors at the XML representation level because it's too difficult and because they will be detected later anyway at the component level. But this seems to be a case where the mapping rules are deliberately triggering an error by generating an invalid component, and that seems a little perverse; it's certainly unhelpful to the reader. To me it would seem less artificial if we allowed errors to be detected in the course of evaluating the mapping rules: saying "in this situation there is no mapping" rather than "in this situation the mapping is to a component X, which by the way is not actually a valid component". For this case I certainly think it's worth adding the note. I also think it's worth unravelling the tortuous prose of this rule. Something like the following (though I'm not sure about how we number clauses here): 2 If the {base type definition} is a complex type definition B, and all the following conditions are true: 2.1 B.{content type}.{variety} = mixed 2.2 B.{particle} is a Particle which is ·emptiable· as defined in Particle Emptiable (§3.9.6.3) 2.3 the <restriction> alternative is chosen, then the appropriate case among the following: 2.4 if there is a <simpleType> S among the [children] of <restriction>, a simple type definition which restricts the simple type definition corresponding to S with a set of facet components corresponding to the elements among the <restriction>'s [children] that specify facets, as defined in Simple Type Restriction (Facets) (§3.16.6.4); 2.5 if there is no <simpleType> and no element that specifies a facet among the [children] of <restriction>, then xs:anySimpleType 2.5 otherwise, there is no mapping defined and the schema is invalid.
During its 2008-12-12 telecon, the schema WG adopted a proposal to address this issue. The proposal can be found at (member-only): http://www.w3.org/XML/Group/2004/06/xmlschema-1/structures.b6235.html The change is very similar to the suggestion given in comment #1. A new note is inserted after clause 2: Note: If there is no <simpleType> among the [children] of <restriction> (and if therefore SB is ·xs:anySimpleType·), the result will be a simple type definition component which fails to obey the constraints on simple type definitions, including for example clause 1.1 of Derivation Valid (Restriction, Simple) (§3.16.6.2). With the addition of this note, the WG believes that the issue raised in this bug report is addressed. I'm marking this RESOLVED accordingly. Michael, if you would indicate your concurrence with or dissent from the WG's disposition of the comment by closing or reopening the issue, we'll be grateful. If we don't hear from you in the next two weeks, we'll assume that silence implies consent.