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.