@qt4cg statuses

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.

If an fos:result contains errorref elements, allow those errors to be accepted as a pass.

Fix #2561

Fix #2575

I propose adding an option to parse-json and json-doc whose value is a list of named record types that might occur within the JSON; if a JSON object is read during parsing, it will be matched against these named record types, and if it matches, the result is a record (with type annotation) rather than an ordinary map.

This should make it easier to process the parsed JSON using XSLT match patterns (or XQuery typeswitch).

F+O §22.4 says

In the case of an implementation that supports XSD 1.1, there is a constructor function associated with the built-in union type xs:error.

We should make the existence of this function unconditional.

Attempt to tidy up the RELAX NG grammar

1. Removed constraints on attributes vs. shadow attributes
2. Generally removed co-constraints except for simple, required attributes
3. Added a few more data types

I’m thinking about trying to translate the XSD asserts into Schematron rules, but I guess that can be a separate PR if I make it work

This test case is marked as having a "narrative" result, but the narrative result allows a dynamic error, and the generated test case doesn't allow for this.

I propose dropping the map:keys-where function.

One of the suggestions in issue #2312.

The function isn't needed very often, and it's easily achieved in other ways. For example, to find all the keys of entries that are non-empty, you could use map:keys-where($map, fn($k, $v){exists($v)}), but it's just as easy to use

map:filter($map, fn($k, $v){exists($v)}) => map:keys()

or

map:for-each($map, fn($k, $v){$k[exists($v)]})

or

for key $k value $v in $map where exists($v) return $k

or

map:keys($map)[exists($map(.))]

With having looked at the details, I assume that example with narrative results should be excluded from the generated tests.

For example, a test is generated for system-properties()?#schema-aware (which is: true for a schema-aware processor, otherwise false.):

<test-case name="fo-test-fn-system-properties-002">
  <description>Test case for fn:system-properties</description>
  <created by="Michael Kay using generate-qt3-test-set.xsl" on="2026-03-31"/>
  <environment ref="global"/>
  <test>
    system-properties()?#schema-aware
  </test>
  <result>
    <assert>true()</assert>
  </result>
</test-case>