@qt4cg statuses

The adaptive serialization method was introduced “for the purposes of debugging query results”. For our processor, it has turned out pretty soon that it does not satisfy the requirements of our users, which is why we have introduced a custom debugging method.

I wonder what others think: Shouldn’t we relax several of the rules and let the implementation decide what to output? We haven’t defined either how the output of fn:trace needs to look like.

Some examples:

• The output of doubles often causes confusion. If parsed JSON is output, small integers will be output in exponential notation. For example, parse-json('{ "A" : 20 }') needs to be output as { "A": 2.0e1 }.
• xs:date("2001-01-01") is output as xs:date("2001-01-01"), while xs:token('x') is output as "x".
• fn() { 1 } is output as (anonymous-function)#0, whereas an implementation could prefer to use the output of fn:function-identity (see #2388), or output the original query string (if available), reproduce a string representation of the function body, etc.

I will be glad to create a PR.

The serialization specs defines rules for creating a string representation for function items. Now that we have `fn:function-identity', we should replace the rules and use this string instead.

Addresses part of issue #641

In the JSON serialization method, NaN is output as null, and infinity is output as ±1e9999.

The parse-json function adds recommendations on how to achieve round-tripping of these values.

Changes the stylesheet for generating keyword and function signature tests so that the namespace prefix "output" is explicitly declared in the test environment. This prefix is used in one of the tests and it needs to be declared if the test is to work in XPath.

Probably XQuery too. I have no idea why.

The type signature of the xsd-validator function suggests that it can be used to validate attribute nodes (as well as documents and elements), and the prose description concurs with this. However the function summary says "can be invoked to validate a document or element node against this schema."

Test case xsd-validator-092 expects an attribute node to be rejected.

Also the Notes in the specification say

The validation process is explained in more detail in the XQuery ([[XQuery 4.0: An XML Query Language]] section [4.25 Validate Expressions] and XSLT ([[XSL Transformations (XSLT) Version 4.0]] section [25.4 Validation]

but the detailed description has since been moved to F&O 17.2.4.

Note that XSLT has always allowed validation of free-standing attribute nodes, but the validate expression in XQuery allows only document and element nodes.

Per #2315:

1. Added ‘at-risk’ changes to the fn:insert-separator, array:members, and array:of-members
2. Added ‘at-risk’ changes to the XPath/XQuery section on map and array filtering
3. Added a note about what ‘at risk’ means to the status sections

These should have no effect without additional commits, but they have to be merged into main in order to have a visible effect on my subsequent PR.