Thank you, Tony, for your comment.  Feedback from practitioners is
always helpful, and we are grateful for your time and interest.

The XML Schema Working Group has discussed your proposal at length,
and I took an action to summarize the upshot, with input from other WG
members.  I am delinquent not to have done so before now, but hope the
delay has not been unduly inconvenient for you.  [I should acknowledge
the assistance of my fellow WG members Fabio Vitali and Paolo
Marinelli of the University of Bologna in the preparation of this
response; any errors it contains are mine.]

I regret to say that while the Working Group has a certain sympathy
for your arguments, the consensus within the group was against making
the change you suggest and allowing assertions on element
declarations.  In the course of the discussion, three main arguments
were brought forward against the plan.

1) It seems to run counter to what the WG regards as an important
design principle distinguishing between element declarations and type
definitions. 

Basically, type definitions are meant to define the legal content of
elements, while element declarations provide the context for these
definitions. This is why element declarations allow the schema author
to specify only those constraints that do not affect what should and
what should not be considered legal INSIDE the element being declared;
that's the job of the type definition.  Occurrence constraints are an
example of this division of labor: they appear on element declarations
in the XML syntax, and they look outward, not inward. 

Clearly, assertions within element declarations would represent an
exception to the principle, since assertions limit the set of legal
instances of content within the element.


2) Second, you observe that the set of applicable assertions may vary
with context.  The WG doesn't disagree, algthough our instinct (in the
light of the design principle just outlined) is to say that that's
prima facie evidence that related but different types are being used
in the different contexts.

However one analyses the situation, the WG believes that workarounds
exist that address the scenarios you mentioned in a rather satisfying
way. For instance, in order to associate assertions to a specific
element declaration, it is always possible to use an anonymous type
definition deriving from the desired type and adding the additional
assertions.  

I believe your second paragraph is intended as a refutation in advance
of our suggestion, but I am not sure the refutation is successful.
You are right to observe that the workaround we suggest will involve
the use of local element declarations in the different places where
different assertions are required.  (Almost right, that is, because
one could simply use several different global element declarations
with different names; I assume that you pass that option over in
silence as undesirable for other reasons.)  But the solution you
propose, viz. attaching different assertions to the different contexts
by using different element declarations, will itself also involve the
use of different local element declarations -- or of global element
declarations with different names.  So I respectfully suggest that
your second paragraph does not succeed in making a case against this
workaround.


3) Finally, there is a practical consideration. The introduction of
the proposed amendment would represent a modification with a heavy
impact on the current state of the XSD 1.1 draft. Its ramifications
would require that we revisit a dismayingly large number of
well-established decisions (such as restriction is subsumption, unique
particle attribution, etc.) that would have to be re-discussed from
scratch. As a result, it would require a substantial workload by the
WG. Given the current status of Last Call Public Working Draft of XSD
1.1, and given the existence of workarounds, the WG believes there is
not enough time for further discussion of this proposal for the time
being.


Given the motivations discussed above, the end of the WG's discussion
was a decision to close this bug without further action.  The status
might be marked either as WORKS FOR ME or as WON'T FIX; the former
would reflect the Working Group's view that the association of
assertions with types and not with attributes is a design decision
correctly made, and not a bug.  But a case could be made that even if
one accepts that the decision was misguided and constitutes a bug, the
second and third arguments given above amount to arguments that the
bug is not fatal (there are workarounds) and that fixing it would be
more costly (in time and in risking the successful completion of the
spec before our charter expires) than not fixing it; the status could
thus as easily be set to WON'T FIX.  I am marking it as the latter.

I hope that the paragraphs above will show that the Working Group gave
serious attention to your comment, and persuade you to see the matter
as we do.  If they have done so, please indicate as much by changing
the status of this issue to CLOSED.  If you are not persuaded and wish
to continue the discussion or to appeal the decision to the Director,
please indicate this by changing the status to REOPENED.

If we don't hear from you in the next couple of weeks, we will take
your silence as indicating assent, and we'll change the status to
CLOSED.

One further note on the design distinction between element
declarations and type definitions, speaking here for myself and not
for the Working Group.

The design distinction is apparently not always obvious to all
observers, the XSD spec probably does an imperfect job of explaining
it or making it clear, and there are certainly some gray areas. But
the basic idea is quite simple.  In our initial design phase the WG
gave the name "the tag/type distinction" to the principle that XSD
distinguishes between two types of information, and correspondingly
two types of schema component.

Context-independent properties which distinguish legal elements from
illegal elements are defined by type definitions.  The name to be
found in the element (its generic identifier, as SGML users say), the
binding of a particular element to a type, and context-relative rules
like identity constraints and nillability are defined in element
declarations.

In SGML and XML DTDs, by contrast, all constraints are captured on the
element declaration and the corresponding attribute list declaration;
there is no notion of a common set of constraints to which several
distinct element declarations may bind their instances.  (DTD authors
commonly capture such commonalities by using parameter
entities. Parameter entities are too low-level to capture such
information reliably and clearly, but the widespread use of parameter
entities to capture common constraints does suggest that vocabulary
designers have often distinguished, however informally, between tag
and type.  XSD tries to make the distinction more regular and
tractable.

Some observers object that if constraints on elements are to be given
in type definitions, not in element declarations, then nillability and
identity constraints should be part of type definitions, not part of
element declarations.  XSD follows SQL in treating both the occurrence
of nil values and referential integrity constraints from the type
system.  (In SQL, both the NOT NULL declaration and the identity of
primary, alternate, and foreign keys are associated not with types but
with columns and sets of columns.)

Thank you for your consideration this issue.  It's never possible to please anyone in this standards business, and I knew from the outset that my request that my request was not such a simple or trivial one.  I'm happy to close this issue now, and I'm looking forwards generally to XML Schema 1.1, which looks like it will deliver many worthwhile improvements.