@qt4cg statuses

Fix #2681

map-for-key() was introduced by PR #1622.

• Since the second argument of map-for-key() is optional, it should allow an empty sequence for consistency.

• The current spec does not define the order of entries in the resulting map. It should specify that the order is implementation-dependent.

• In the third paragraph of the Errors section, the reference to the key function should be a reference to map-to-key.

• The spec says: The returned map contains one entry (K, V) for every atomic item K where the result of key($key-name, K, $top) is not empty, with V set to the result of key($key-name, K, $top). But there can be an infinite number of items that satisfy this condition, for example, QNames with different prefixes. We should only return one key for each "equality group" in the underlying index. That's a slightly slippery concept, but essentially we should return the entries with distinct keys, on a suitable definition of "distinct".

• Underlying this is a slight implementation difficulty: the spec for xsl:key and the key() function does not actually require us to hold the "real" key for an entry, in the sense of the result of the use expression. We can instead hold some kind of internal "collation key" used for matching. It's not always possible to reconstruct the original atomic value from the collation key. In most cases (given that we require the key to use codepoint collation) we can construct an equivalent key, and I think that's all that the spec should require. For example, this means we aren't required to deliver the original type annotation, the original timezone, or with QNames, the original prefix.

I think we can say something like:

Let UU be the set of atomic items U for which the result of key($key-name, U, $top) is not empty, and let KK be the result of eliminating duplicates from UU according to the rules of the atomic-equal function. (Note, the set UU is potentially infinite: for example in the case of QNames, there is an infinite set of prefixes that can be chosen for a QName. The set KK, however, is always finite, and contains one value for each set of equivalent values obtained by evaluating the use expression in the key definition. The particular choice of atomic item from the set of candidate values is implementation-dependent; for example, with QNames, the item chosen might be one that has no prefix. The chosen key is not necessarily one that actually arose from evaluation of the use expression: for example, it might have the type annotation xs:string when all the original keys were instances of xs:untypedAtomic.) Then for each atomic item K in the set KK, the returned map contains an entry (K, V) where V is the reuslt of fn:key($key-name, K, $top).

XSL Transformations (XSLT) Version 4.0 W3C Editor's Draft 26 May 2026

In sections

• 27.6 Binary Library Feature, points 4 and 5 in both conformant/non-conformant sections
• 27.7 File Library Feature, points 4 and 5 in both conformant/non-conformant sections

Is it a copy/paste error that fn:system-property and fn:system-properties use what I think is XQuery syntax?

4. must return "yes" as the result of the expression fn:system-property(#xsl:supports-file-library).
5. must return true as the result of the expression fn:system-properties()?#supports-file-library.

I'm not finding the information at "Available pull requests" (https://qt4cg.org/available-prs.html) useful.

I thought that the idea was to publish a minimised diff showing the effect of the PR on the spec, so that we could easily go back and see what changes the PR had made. But what we get appears to be a complete version of the spec (all the specs) with no indication of changes.

A thorough revision of the section on patterns, based on the whiteboarding done in Prague. The main technical changes are:

• GNodePatterns become XNodePatterns, and apply to XNodes only
• Revise map patterns to distinguish extensible from non-extensible patterns
• Add array patterns
• Reintroduce JNode patterns (which still had a ghostly presence in the spec....)

There's a fair bit of editorial rearrangement as well, so the diffs probably won't be too helpful.

On fn:transform, the description for the 'serialization-params' option says:

Serialization parameters for the principal result document. The supplied map follows the same rules that apply to a map supplied as the second argument of fn:serialize.

Then it describes how an unnamed xsl:output is used as default parameters. But fn:serialize does not describe the use of xsl:output, because I don't think it's supposed to, so saying that it follows the same rules is misleading to me.

Fix #2672

Implements one of the suggestions in #2664, allowing element-to-map() to accept a well-formed document node.

I'm not in favour of pursuing the other suggestion in that issue, namely atomizing a map (or a JNode) to extract its string-value (as the concatenation of the map entries).

Fix #2664

A sequel, starting with Gunther’s observation in the last comment of #2590:

• [ ] XQuery: A.1.2 Constraint: reserved-function-names uses the term "unprefixed" as one of the characteristics of disallowed function names. This may lead one to believe that a URIQualifiedName without a prefix might possibly qualify for being restricted. However, this seems unlikely to be intended: the Q{...}... syntax is unambiguous and cannot be mistaken for a KindTest or similar construct. I thus propose to clarify this in the constraint, by dropping "prefixed"/"unprefixed" from it, or adding a remark about URIQualifiedName.

Fix #2590

I want to revive Mike’s idea of introducing a trace clause (#111):

Despite the recent spec including fn:message, it remains cumbersome to output intermediate results or provide progress information inside FLWOR expressions. I think that a message clause with one expression and an optional label expression…

for $item in //items
message $item/@id, 'ID: '
return string($item)

…would be a good drop-in replacement for clumsy temporary let clauses…

for $item in //items
let $_ := message($item/@id, 'ID: ')
return string($item)

The clause would be evaluated once for every tuple reaching that clause. It seems sensible to me to stick with the value/label structure, as existing trace code can build on it without further changes.

Since the evaluated value is swallowed, I have chosen message as keyword, but trace may work similarly well.

PS: I promise I’ll hold off on sharing new ideas for the upcoming weeks…

Fix #2668

Fix #2669

Given the debates we've been having about empty entries in a record versus absent entries, it would be useful to have an option on the deep-equal function to treat these as equivalent.

Perhaps "empty-as-absent" - treats map entries whose value is an empty sequence as if the entry were absent. Default false.