@qt4cg statuses

Locating Packages

In the example at the end of 3.4.3 Locating Packages there is a version attribute on the xsl:use-package element. I initially thought it was the XSLT version value but on looking closer that was wrong. So shouldn't it be a package-version attribute?

Also, I would expect the package-location elements to be xsl:package-location.

Examples of Stylesheet Functions

In the first example in 10.3.8 Examples of Stylesheet Functions the XSLT version is '3.0' but the xsl:if is using the then and else attributes from '4.0'. I would expect the XSLT version to be '4.0'.

General question about XSLT version in the examples

Generally the XSLT version is still set to '3.0' in most of the examples. Should it be uplifted to '4.0'?

Fix #1949

Refines the rules for inferring boolean and numeric data types.

Fix #2685

Proposes that the strip-space option should work the same way across fn:doc and fn:document, with the option strip-space="conditional" taking account of xsl:strip-space declarations when running in XSLT, for compatibility.

The way in which function options are rendered for the fn:document function in XSLT is different from (and inferior to) that for the fn:doc function in F&O.

The strip-space option is defined as a boolean in both the fn:doc and fn:document functions, but

• The meaning of strip-space:true() differs between the two specs. In fn:doc() it means strip all whitespace text nodes (subject to various conditions), in fn:document() it means "do what the stylesheet says", i.e. follow xsl:strip-space and xs:preserve-space declarations.

• The default value is also different.

In XPath 3.1, fn:doc didn't mention whitespace stripping as a possibility, but XSLT 3.0 said that the whitespace stripping process (controlled by xsl:strip-space) applied to "any source tree", which was defined as including documents read using fn:doc() or fn:collection().

I suggest that for both fn:doc() and fn:document() (and for fn:collection when we define the options for that function), strip-space should have three values: all, none, and conditional. The value all corresponds to true as currently defined for fn:doc; none corresponds to false as defined by fn:doc; conditional means "as determined by the host language, or false by default" with a note pointing to xsl:strip-space. The default for both functions should be conditional.

Can casting to type T return a value whose type annotation is a subtype of T?

Section 23.1 says explicitly that it can:

Where the target type TT is a primitive type, the result TV [of casting to TT] will always be an instance of TT. The result may also be an instance of a type derived from TT: for example casting an xs:NCName SV to xs:string may return SV unchanged, with its original type annotation.

Section 23.3.4 says explicitly that it can't:

The result will have the same value as the original, but will have a new type annotation:

• If T is an atomic type, then the type annotation of the result is T.

There are arguments both ways; we need to make a decision.

The argument in favour is substitutability: any expression should be able to return a subtype of the required static type. For example given abs(X), if X is of type xs:positiveInteger then it should be permitted to return the argument unchanged, rather than changing its type annotation.

The argument against is that this can affect interoperability. If different implementations return values with different type annotations, that can affect the result of "instance of" and "typeswitch" expressions, and of XSLT pattern matching. But this argument would apply to all expressions, not only to casts and constructor functions.

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.