@qt4cg statuses

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>

Clarification for empty directories (which should always be deleted, as defined earlier).

Closes #2553

The spec appears to give conflicting rules for resolving unprefixed function calls when an explicit default function namespace is declared.

Example:

declare default function namespace "urn:test";
declare function f() { "namespace" };
declare function Q{}f() { "no-namespace" };
f()

Two readings seem possible:

• from 5.14.2 Default Function Namespace Declaration and the 2.2.1 Static Context component "default function namespace": f() refers to the function in "urn:test", yielding "namespace"
• from the default function namespace rule: the no-namespace function is preferred, yielding "no-namespace"

Is err:FODT0006 really necessary? Why does it need to be distinct from the existing err:FORG0001, Invalid value for cast/constructor? Other error codes make it possible to distinguish between a date/time formatting error (err:FOFD1340, err:FOFD1350), an invalid combination of date/time components (err:FODT005) and other date-related errors. If the purpose of err:FODT0006 is to be more targeted, dedicated to an invalid value for a component of a date/time, then shouldn't it be general to the same circumstances in all date/time constructor functions rather than specific to fn:build-dateTime?

Similarly, if the invalid value is for the timezone component, then I'd like to propose that err:FODT0003 invalid timezone value should be re-used instead of the more generic err:FODT0006.

In both XQuery and XSLT, it would be useful to allow one named record type to be declared as an extension of another, to avoid duplication between the definitions.

First cut for review: the PR probably needs further passes before it is ready for acceptance.

We introduce the idea of records, being maps that have a type annotation which is a specific record type. A map acquires the type annotation when it is coerced to the record type. A map that has a record type annotation (a "record") throws a type error if map:get() (or a lookup expression) requests a key that is not one of the declared field names for that type. The type error can be raised statically.

map:put() applied to a record is constrained to produce a record with the same type annotation. (I've no objection to the "with" operator for this, but that can be done separately.)

Optional fields in record types are dropped; in a record, there is no distinction between an absent field and a field whose value is the empty sequence. There is no longer any need for this distinction, and eliminating it simplifies things a lot. (But we will need to decide whether to treat the fields as present or absent when serialising to JSON).

Fix #1979