@qt4cg statuses

Fix #2592

Also changes the null option to be of type item()? rather than item()*. With the current spec, a top-level "null" could expand to multiple items which would violate the declared return type of the parse-json function.

With 4.0, fn:parse-json has been equipped with a number-parser option. It works fine if you know your data in advance. User feedback indicates that it fails to deliver a convenient solution for arbitrary input. In addition, it requires a configuration which allows you to specify function items as options (which is tricky, for example, for command-line options).

Would we take a big risk by making the interpretation of numbers more flexible? We could adopt the rule for fn:element-to-plan, which says:

If the prescribed type is numeric and the value is castable as xs:numeric, then it is output as an instance of xs:integer, xs:decimal, or xs:double depending on the lexical form of the value, following the same rules as for XPath numeric literals. For example, "-1" becomes an xs:integer, 12.00 becomes an xs:decimal, and 1e-3 becomes an xs:double.

I would see many advantages; among other:

• Obvious integer input could be handled as such without further conversions.
• We will have fewer losses in roundtripping scenarios with large numbers and many decimal places.
• Debugging with the adaptive serialization method would become handier (without changing it, see #2389):

(: current result: 1.0e1 :) 
declare option output:method 'adaptive';
parse-json('10')

With this change, I assume that number-parser option can be avoided in most cases, and I cannot think of big trouble that the introduced backward-incompatibility could cause.

According to the current grammar, I believe that step?lookup is not a valid expression. My reasoning (let’s see if I missed something):

1. step on its own is not a PrimaryExpr. A name can only occur as a NameTest inside StepExpr/AxisStep.
2. A lookup attaches only to a PostfixExpr, which starts with a PrimaryExpr.
3. Inside a RelativePathExpr, consecutive steps must be separated by / or //.

I think we can live with the restriction, but it may be a reason for avoiding wild mixtures of paths and lookups in practice.

Related is the last example in map:build. It uses ./ancestor-or-self::jnode()?name, and I think it needs to be (./ancestor-or-self::jnode())?name.

Carrying on the tradition of #2408:

• [ ] FODC0013: Raised when the the options
• [ ] …

To keep the list short, I will incremental edit my existing comments until the next PR is finalized.

Defines streamability rules for new 4.0 constructs impacted by the generalisation of context item to context value.

Fix #2587

In the latest version of PR #2566, the xsl:record instruction has been dropped from XSLT. This needs to be revisited when the dust has settled: does an instruction of this kind actually add value, and if so, what form should it take?

I think that many of the streamability rules in the XSLT 3.0 specification rely on the assumption that the context value will be a single item.

Revising the analysis to handle the generalisation is not only a major piece of work which we are ill-resourced to attempt, it may well have the result that many constructs which were streamable in 3.0 are no longer streamable in 4.0.

I'm therefore inclined to push back on this change, or at any rate to find a way to limit its scope.

Fix #2408

Rules regarding limits are scattered around the specifications somewhat arbitrarily. I suggest that they be moved to a single place in the Data Model specification, and unified across XSLT, XPath, and XQuery.

I think we should have another thought about JNodes and absolute path expressions. A simple XPath expression that starts with a slash should definitely succeed if a map or array is provided as context value, either externally or via declare context value:

declare context value := { 'data': 123 };
/data

Maybe we could also try to simplify the rules in the specification ([4.6.1 Absolute Path Expressions](https://qt4cg.org/2026-01-28/xquery-40/xquery-40.html#id-absolute-path-expressions)):

The expression consisting of / on its own is treated as an abbreviation for the path expression /..

An expression of the form /PP (that is, a path expression with a leading /) is treated as an abbreviation for the expression self::gnode()/(fn:root(.) treat as (document-node()|jnode())/PP. The effect of this expansion is that for every item J in the context value V:

1. A type error occurs if J is not a GNode [err:XPTY0020].

This seems confusing to me. My assumption is that…

declare context value := { 'data': 123 };
data

…does not raise an error. Why would self:gnode() do so, which is also a single relative XPath step?

Related: #2359

declare type app:invoice as map("xs:string", element(inv:paid-invoice)); should not use "xs:string" but xs:string

Can we change the return type of bin:hex from xs:base64Binary to xs:hexBinary? This way, we could get rid of baffling constructs like:

'41' => bin:hex() => xs:hexBinary()

It would be a backward-incompatible change, but one that will hardly be noticed: thanks to the 4.0 coercion rules, xs:hexBinary and xs:base64Binary can now be used interchangeably.

The semantics of patterns in XSLT have been changed so that the patterns for XNodes and JNodes are completely distinct. However, this is not reflected in the prose, which still has a single section describing "GNodePatterns" implying that the same pattern can match both. Fixing this is largely editorial, though it may benefit from some refactoring of the grammar.

Having dropped extensible record types, we are now left with no easy substitute for the convenient XSLT match pattern

match="~record(first, last, *)"

which would match anything having fields first and last.

I propose we fill the gap with a "map pattern" which might take the form

match="{first, last}"

or

match="{first: ~enum('John', 'Jane')}"

or

match="{r: ~xs:double[. ge 0], i: ~xs:double[. ge 0]}"

What follows the ":" is an optional SequencePattern, defined as a Pattern followed optionally by an OccurrenceIndicator.