This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 28980 - [F+O3.1] Definition of expanded-QName
Summary: [F+O3.1] Definition of expanded-QName
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Functions and Operators 3.1 (show other bugs)
Version: Last Call drafts
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-07-21 08:01 UTC by Michael Kay
Modified: 2016-12-16 19:55 UTC (History)
1 user (show)

See Also:

Attachments

Description Michael Kay 2015-07-21 08:01:23 UTC 
The definition of expanded-QName in the F+O spec needs to be brought into line with the definition in other specs: XDM, XPath/XQuery, and XSLT all define it as a triple, but F+O still describes it as a URI/local-name pair.
Comment 1 Andrew Coleman 2015-09-01 15:34:23 UTC 
Agreed editorial fix
Comment 2 Michael Kay 2015-09-02 16:28:02 UTC 
I have changed the definition to be the one used in the XSLT specification:

 An <term>expanded-QName</term> is a value in the value space of the <code>xs:QName</code> datatype as defined in the XDM data model (see <bibref ref="xpath-datamodel-31"/>): that is, a triple containing namespace prefix (optional), namespace URI (optional), and local name. Two expanded QNames are equal if the namespace URIs are the same (or both absent) and the local names are the same. The prefix plays no part in the comparison, but is used only if the expanded QName needs to be converted back to a string.