Agreed in principle that we should add a statement that the order is implementation-dependent. And agreed to change it to editorial/minor.

I propose to add two statements to the specification:

(1) the result sequence contains no duplicates

(2) the order of items in the result sequence is implementation-dependent

Since (1) might be considered by some to be a technical change in the specification (there is nothing at present which explicitly requires duplicates to be eliminated) I am raising the priority back to "normal" to get WG endorsement for this resolution.

Discussion in meeting 419 led to this action:

ACTION A-419-01 Michael Kay to propose resolution to bug 7092. Define the
function in-scope-prefixes in terms of properties in the data model. Need to
check that XDM has the appropriate non-uniqueness constraint. And to handle
the inconsistency with the language documents.

What we identified was that the current description of the function was weak in that it didn't tie up with anything in the data model. For example, if the data model says that prefixes are unique, then the function description should not need to repeat this.

The relevant accessor in the data model is dm:namespace-bindings, defined thus:

http://www.w3.org/TR/xpath-datamodel/#dm-namespace-bindings

"The dm:namespace-bindings accessor returns the dynamic, in-scope namespaces associated with a node as a set of prefix/URI pairs, using an implementation-dependent representation."

Curiously, the function prototype gives the result type as xs:string*. How this sequence of strings is used to represent a set of pairs of strings is anyone's guess - but I sympathise with the author's problem.

Describing it as a "set of prefix/URI pairs" does not in itself say that there cannot be two pairs with the same prefix (mapped to different URIs).

Section H.7 repeats that in the case of element nodes, the accessor returns a set of pairs, but curiously for other kinds of node it returns not an empty set but an empty sequence. (But F+O invokes the accessor only for element nodes).

The accessor in the case of element nodes is defined in terms of the "namespaces" property of the element node, but the spec actually says very little about what that property is. Sometimes it appears to be a set of namespace nodes, sometimes it appears to be a set of prefix/URI pairs. Perhaps the ambiguity is deliberate?

Consistency constraint 13 in the description of element nodes (6.2.1) gives up talking about the namespaces property entirely, and instead talks about namespace bindings and namespace nodes.

I can't find any constraint in the data model that the namespaces of an element must all have distinct prefixes. (Equally, I can't find a constraint that the attributes have distinct QNames.)

Generally, I'm obliged to conclude that for 2.0, the data model does not provide a very solid foundation for defining this function, and we are therefore better off patching it up with sticky tape. Perhaps we can do better in 2.1, but it will need a thorough rewrite of the way namespaces are described in XDM, taking into account the above input.

So my proposal for a 2.0 erratum, as a minimum fix for this bug report, is to change the specification of fn:in-scope-prefixes as follows:

Replace the current text:

<old>
Summary: Returns the prefixes of the in-scope namespaces for $element. For namespaces that have a prefix, it returns the prefix as an xs:NCName. For the default namespace, which has no prefix, it returns the zero-length string.
</old>

by

<new>
Summary: Returns the prefixes of the in-scope namespaces for $element.

The function returns a set of strings, corresponding to the prefixes of the in-scope namespace bindings for $element, as delivered by the dm:namespace-bindings accessor [DM]. 

For a namespace binding that has a prefix, it returns the prefix as an xs:NCName. For the default namespace, which has no prefix, it returns the zero-length string.

The result is represented as a sequence of strings containing no duplicates, in implementation-dependent order.

Note: the result will always include the string "xml", since a binding for this prefix is always in scope. It will include the string "" (representing the default namespace) only if there is a default (non-empty) namespace in scope for $element.
</new>

with corresponding changes to F+O 1.1 until such time as a more solid description is in place in XDM.

The proposed wording was accepted on 2010-01-05 subject to saying that "duplicate" prefixes are determined by codepoint comparison.

(Liam also pointed out the need for careful wording as regards the "default namespace")

For the record: this agreed change has been applied in the 3.0 specification, but it did not make it into the second edition of the 1.0/2.0 specification.

I have added it to the list of candidate errata for the 1.0/2.0 specification, and with that I am closing the bug so that it no longer comes up as needing attention.