@qt4cg statuses

Add a regex($pattern, $flags) function to construct a "compiled" regular expression. This gives a clear signal that the same regular expression might be used repeatedly; it avoids relying on caching, which can be unnecessarily expensive and is not predictable across implementations.

Two possible ways this might work:

(a) allow the result of the regex() function to be used as an argument to functions such as matches(), tokenize(), etc, in place of the $pattern and $flags arguments

(b) make the regex() function return a record with methods matches(), tokenize(), replace() etc whose functionality corresponds to the existing functions.

The second approach seems easier to fit into the type system. With the first approach, it's unclear what kind of value the regex() function should return.

Some of the syntax scraps in the XSLT spec recurse much too deeply, see for example 6.3.2.1 Predicate Patterns

In the XPath/XQuery specs, the expansion stops when a construct is reached whose name appears at the head of its own scrap. This doesn't work for XSLT patterns because the expansion is in a different spec.

Fix #2580

Edits here were motivated by several points that caused me confusion tonight:

• 4.1.2 and 4.1.5 had duplicate text, an indication that they belong next to each other.
• In 4.1.2 there were no pointers to the definitions of the datatypes discussed.
• The fifth bullet point in 4.1.2 is not a schema type (which is the topic of the unordered list). The material belongs outside the list.
• The fifth bullet point claims that XDM defines two data types, but it doesn't. And it doesn't mention another data type discussed in predefined data types.
• There is a long discussion of xs:error in the XPath specs, but the reader of this section has no clue on where xs:error is defined or explained.

Etc. I suspect my draft here still has problems, but I hope it's an improvement.

Closes #2389

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.