This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I can't find a qname->uri mapping in http://www.w3.org/TR/2005/WD-xpath-functions-20050404/#namespace-prefixes ala http://www.w3.org/TR/webarch/#qname-mapping [This entry added by CMSMcQ from Dan Connolly's email at http://lists.w3.org/Archives/Public/public-qt-comments/2005Apr/0112.html]
Our specifications appear to make use of the following namespaces: Standard Standard Prefix URI dm: none err: http://www.w3.org/2004/07/xqt-errors fn: http://www.w3.org/2005/04/xpath-functions fs: none local: none op: none xdt: http://www.w3.org/2005/04/xpath-datatypes xqx http://www.w3.org/2005/04/XQueryX xsl: http://www.w3.org/1999/XSL/Transform We have defined several of these prefixes without a corresponding URI because they exist only as an editorial device or because they describe things that are completely abstract and we have no reason to refer to them in any concrete sense. But Dan has demonstrated that it may be useful for the larger community as a whole to be able to identify even the things that we consider abstract using URIs. In particular, I believe that Dan wanted to define one of our operations in a semantic web context and found that there was no URI for it. In that light, I think it probably makes sense to provide real URIs for the dm: fs: and op: prefixes, in addition to the prefixes that we have already defined. Concretely, I propose: Standard Standard Prefix URI dm: http://www.w3.org/YYYY/MM/xpath-data-model fs: http://www.w3.org/YYYY/MM/xpath-formal-semantics op: http://www.w3.org/YYYY/MM/xpath-operators I really don't think there's any reason to define a URI for the local: prefix, but I'm not really sure I understand how "local:" works in XQuery so I could be wrong. Each of our namespaces needs a namespace document. I'm willing to produce the namespace documents for the dm:, fn:, and op: prefixes. I can probably be persuaded to take on some others, if no one else volunteers. Per the good practice[1] in WebArch[2], we must provide a mapping from QNames to URIs. That is, there must be a way to translate the QName pfx:localname into a URI. I propose that we adopt a single definition for all of our specs: the URI of the resource identified by pfx:localname is concat(namespace-uri(pfx:localname), '#', local-name(pfx:localname)) I suggest that we write a working group note that outlines our suite of namespaces and our QName to URI mapping. [1] http://www.w3.org/TR/webarch/#qname-mapping [2] http://www.w3.org/TR/webarch/
Sorry, but adding namespace URIs to the abstract prefixes are highly problematic since we would have to define semantics for XSLT and XQuery specifications to disallow users to use these URIs which is problematic in its own right. If the RDF folks want to refer to these functions, they better define their own URIs in their domain and refer to the definition.
The QT WGs discussed this on 5/19/2005 and agreed with the form suggested for the URIs: > the URI of the resource identified by pfx:localname is > concat(namespace-uri(pfx:localname), '#', local-name(pfx:localname)) They did not, however, approve the rest of the suggestions for QName to URI mapping.