This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
[This is (a generalization of) the same issue that I raised in Bug 1660, Comment #2, but I figured it deserved its own Bug.] I'm fairly certain that QNames don't belong anywhere within (Formal) Values, Types, or Definitions. The problem is that a QName generally only has meaning with respect to an environment of namespace bindings, and Values, Types, and Definitions often appear far from their point of creation, where some other set of namespace bindings holds sway. For Values, there's also the argument that FS Values (ultimately) have to map to XDM values, and where an FS Value has a QName (e.g., the name of an element or attribute node), the XDM value requires an xs:QName, i.e. an expanded-QName. The fix starts with changing 'QName' to 'expanded-QName' in the EBNF for Formal symbols: TypeName, AttributeName, and ElementName (in 2.3.1) and ElementNameOrWildcard and AttributeNameOrWildcard (in 2.4.2). While you're there, rename each of those symbols by prepending 'Formal' (or 'Expanded', or whatever), to distinguish it from the Core symbol of (currently) the same name. And then update all affected rules appropriately. Apart from simple renamings, it mostly amounts to shifting around invocations of 'expands to' judgments. (I can give further details if you like.)
The fix for this bug does not appear in the Recommendation of 23 January 2007. It will be considered for a future publication (either an Errata document or some possible future version of the specification).