29988 2016-11-06 18:23:41 +0000 [XSLT30] Function available-system-properties and its returned value 2016-11-11 09:07:16 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Candidate Recommendation PC Windows NT RESOLVED FIXED P2 normal --- 1 abel.braaksma mike public-qt-comments oldest_to_newest 128090 0 abel.braaksma 2016-11-06 18:23:41 +0000 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) 128091 1 abel.braaksma 2016-11-06 18:26:31 +0000 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?) 128094 2 mike 2016-11-07 11:31:31 +0000 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. 128145 3 mike 2016-11-11 09:07:16 +0000 I have added a clarification to the spec.