This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Trying to solve a user's problem just now, I found some wording in section 3.11.1: speaking of key, keyref, and unique the spec says These constraints are specified alongside the specification of types for the attributes and elements involved It having been a while since I worked on any problems involving key and keyref, I was trying, in consulting the spec, to refresh my memory on where identity constraints are allowed. When I read this sentence, I thought that it was providing me an answer: on element declarations and on attribute declarations. Associating a keyref constraint with an attribute provided a simple and elegant solution to the user's problem, which made me feel quite happy about this part of our spec, until I tried to verify the exact syntax to use and learned that I had deceived myself. Instead of associating a referential integrity constraint with an attribute, the user was going to have to associate it with a child element instead. There are two possible ways to improve this situation, not mutually exclusive. First, the discussion of identity constraints ought to be revised editorially to say explicitly somewhere, preferably in the introductory sentences, what kinds of components can carry identity constraints. The suggestion that identity constraints relating to a given attribute are specified "alongside" the type of that attribute should be eliminated -- identity constraints relating to the value of an attribute or an element are declared in some other place entirely, involving some arbitrary choice of ancestor element. Second, unless there is a reason for allowing identity constraints on elements but not on attributes, the WG should consider, in connection with any future version of XSD, a proposal to allow identity constraints to be associated with attributes as well as with elements. This is not an issue urgent enough to delay XSD 1.1; I file this issue only to ensure that it's part of the record available for developers of any future versions of XSD.
An identity constraint defines a constraint on a subtree, namely that two Xs within the subtree can't have the same value for f(X). The declaration of the constraint is associated with the root of the subtree that it constrains. I can't therefore see how it would make much sense to specify the constraint for an attribute, whose subtree is trivial. I've always thought defining the constraint on the type rather than on the element would make sense, but there's no real benefit in making the change at this stage of the game.