12554 2011-04-25 21:36:31 +0000 [F+O 3.0] Clarify terminology for default namespace 2011-06-08 09:54:38 +0000 1 1 1 Unclassified XPath / XQuery / XSLT Functions and Operators 3.0 Working drafts PC Windows NT CLOSED DUPLICATE 12553 P2 normal --- 1 mike mike public-qt-comments oldest_to_newest 47672 0 mike 2011-04-25 21:36:31 +0000 This arises from XQuery test suite bug #11590. In fn:namespace-uri-for-prefix() there are two problems: (a) The term "default (unnamed) namespace" is nonsense: every namespace has a namespace name. What is intended is "default namespace". (b) The sentence "Otherwise, it returns the empty sequence." is preceded by two conditionals, and it's not clear which one the "otherwise" relates to. I believe the first is intended. I propose to recast the rules as follows: Rules If $prefix is the empty sequence, the function behaves as if $prefix were the zero-length string. If $element has an in-scope namespace whose namespace prefix is equal to $prefix, it returns the namespace URI of that namespace. Otherwise, it returns the empty sequence. Prefixes are equal only if their Unicode codepoints match exactly. Note If $prefix is the zero-length string or the empty sequence, then: * if there is a default namespace, the namespace URI of the default namespace is returned * if there is no default namespace (that is, if there is no declaration of the form xmlns="uri", or if there is a declaration of the form xmlns=""), the function returns the empty sequence. The rules for fn:in-scope-prefixes() are also open to misreading. It states "For the default namespace, which has no prefix, it returns the zero-length string." This could be read as meaning that the result sequence always includes the zero-length string. In fact it includes the zero-length string only if the in-scope namespaces contains a binding for the zero-length string (that is, a default namespace), which will be true only if there is a namespace declaration of the form xmlns="non-empty-URI" in force. I propose fixing this editorially. 47675 1 mike 2011-04-25 21:52:15 +0000 *** This bug has been marked as a duplicate of bug 12553 *** 49311 2 mike 2011-06-08 09:54:38 +0000 The resolution of this bug is recorded under the related bug #11590 (raised against the test suite.)