3863 2006-10-26 02:20:18 +0000 [FS] technical: QNames in Values/Types/Definitions 2007-11-04 06:00:05 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Formal Semantics 1.0 Candidate Recommendation All All ASSIGNED P2 minor --- 1 jmdyck jmdyck public-qt-comments oldest_to_newest 12609 0 jmdyck 2006-10-26 02:20:18 +0000 [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.) 14211 1 jim.melton 2007-02-26 00:16:31 +0000 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).