[Bug 3863] [FS] technical: QNames in Values/Types/Definitions

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3863

           Summary: [FS] technical:  QNames in Values/Types/Definitions
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Formal Semantics
        AssignedTo: simeon@us.ibm.com
        ReportedBy: jmdyck@ibiblio.org
         QAContact: public-qt-comments@w3.org


[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.)

Received on Thursday, 26 October 2006 02:20:29 UTC