This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
The function fn:available-system-properties returns a sequence of qnames. At the bottom of its section (bottom of 20.4.5), there's a convenience-function described to convert these into strings that can be used with system-property. While that's a good thing, the function is introduced with: "However, they must first be converted to the form expected by the system-property function. This can be conveniently achieved by passing a QName to the function:" I think it is more accurate to say that this *may* be needed. While the function returns qnames, we can't say anything about their prefixes, but processors are allowed to assign prefixes (right?). In such cases it may be enough to simply cast the qname to a string. With the caveat that the prefix in the string may get out of namespace-scope. But bottom line is, either we should be more explicit as to why we go through the trouble of giving a utility function to the user, or we should settle with "may": "However, they may first need to be converted to ..." (alternatively, can't we request the F&O group to introduce an fn:qname-to-eqname function? It is so weird we have introduced eqnames, but no function at all to handle them)
Perhaps we should also update this sentence: "The function returns a sequence of QNames, being the names of the system properties recognized by the processor, in some implementation-dependent order." into "The function returns a sequence of QNames, being the names of the system properties recognized by the processor, in some implementation-dependent order, with implementation-dependent or empty prefixes." (or is that common sense?)
Casting the QName to a string may work if the implementation and the stylesheet happen to bind the same prefixes, but this is so unreliable that I don't think we should encourage anyone to attempt it. I agree that it makes sense to point out that the prefix component of the returned QNames is implementation-dependent.
I have added a clarification to the spec.