@qt4cg statuses

Adopted from https://github.com/qt4cg/qtspecs/pull/2719#issuecomment-4904849541:

I think that allowing spaces, tabs, and newlines as literal characters representing themselves is hopelessly error prone, partly because it's not distinguishable to the human reader, and partly because serialization parameter values can be written as XML attributes, which are subject to attribute value normalization. Backslashes are less error prone (though when the spec says that the value must match \\t, the spec gets confusing). I would suggest making it simpler: indent-unit="SSS" for three spaces, or indent-unit="T" for one tab, and use newline="NL | CR | CRLF"

The attempt… which closes #2802 if accepted. Much of the prose is derived from the original version of the spec.

I revived the strict type error for fn:deep-equal($fn1, $fn). I believe we shouldn’t re-introduce implementation-dependent behavior; I don’t think it would have enough added value.

…and other editorial fixes.

Closes #2780

Closes #2773

I think we should reconsider whether it was a good idea to give functions public identities:

• It’s a feature you can see but are told not to trust: The result of fn:function-identity will depend completely on the implementation.
• If we keep it, all built-in functions that create functions will need to become non-deterministic (see #1920), with the drawback that the effects of nondeterminism again depend on the implementation. Among others, this includes fn:parse-json, fn:apply, or fn:op.
• It could simplify the prose of fn:jtree. The current notes revolve alot around the function identity, but it is not clear why: Since the identity is unpredictable, the behavior of fn:jtree will be too.

fn:deep-equal could be equipped with an option to ignore functions other than maps and arrays.

I may need a memory refresher: Are there are language features that would suffer from the reversal?

The result of matching-segments() includes for each match, a map containing information about the captured groups for that match.

The result of regex-groups() provides a map containing information about the current match being processed by xsl:analyze-string.

I propose to align the definition of these two maps, which are currently needlessly different.

Closes #2799

Users from other Python may want to use fn:slice to revert a sequence. Reversal works if you supply both bounds:

slice((1, 2, 3, 4, 5), 5, 1, -1)

…but if you omit start and end, you get the empty sequence:

slice((1, 2, 3, 4, 5), step := -1)

I think this can easily be fixed without changing the existing behavior of the function. I’ll write a PR.

Should we output <group nr="1"/> (with the group number) or perhaps <group name="n"/> (with the group name) or perhaps <group name="n" nr="1"/> (with both)?

Closes #2699

Closes #2352

The security feature “trusted” controls whether running code is allowed to reach external resources (like files or web documents). The same word trusted was being used for two different things, which was confusing:

1. Who is running: is the code itself trusted? (This one stays unchanged)
2. What a parse may fetch: when reading an XML document, may it also pull in extra linked things like external entities, a DTD, or XInclude content? (I renamed this one to trust-external).

In addition, I tried to clear up loose ends:

1. It says plainly that “code” is trusted (not “documents”).
2. it adds the missing rule for who is trusted by default: a query you run yourself is trusted; code loaded indirectly (via fn:load-xquery-module, etc.) is not.
3. I clarified that untrusted code cannot grant itself access just by setting the option (access needs both trusted code and the option).
4. Cleanups

Closes #2338

90% mechanical, but it also includes substantial prose.

The editing of the XSLT spec may be incomplete. For example, it still needs to formally state what the node() pattern matches now that node() means any node.

Closes #2748

90% copy & paste; the relevant contents are in the serialization spec. I anticipated the integration of the line-ending parameter of #1234 (however the exact syntax will look like).

Close #2729

I hope it’s less ambiguous now. Closes #2790 No extra QT4 tests needed (the PR contains two new examples).

Starting from https://qt4cg.org/specifications/xpath-functions-40/Overview.html, use "find in page" in the browser to find the text entry orderDM. It's a link on the phrase "entry order". The link target is https://qt4cg.org/specifications/xpath-datamodel-40/Overview.html#dt-entry-order, but clicking the link goes to Overview.html as a whole instead of the definition of entry order.

Same for function itemDM or GNodeDM, which goes to Overview.html instead of the definition of function item or absent, respectively.

Some links go to their specific definitions in other specifications as expected, e.g., do "find in page" on digitXP or absentDM31. Maybe the XDM 4.0 specification is the problem?

Given pad-string("x", 5, {"fill": "0123456789", "side":"start"})

I don't think it's obvious from the spec whether the expected result is 0123x or 6789x (the latter seems preferable to me).

It's even less obvious with side:both.

There don't seem to be any examples that use a multi-character fill string.

Now that "declare type" produces constructor functions, there is no longer any good reason to preserve the overlapping functionality of "declare type" and "declare record".

This PR currently makes the XQuery changes to merge these constructs; I intend to make similar changes for XSLT.

Along the way, there are some other minor changes:

• The definition of Constant now allows the empty sequence, ()
• The initialiser defining the default value of a field in a record type must be a Constant
• The default value for a field is used in coercion from maps to record types as well as in constructor functions
• Creating a constructor function for a named type is optional, by explicit request
• Constructor functions can be created for a record type even if its field names are not all NCNames
• The rule that coercion from maps to record types doesn't allow extraneous fields in the map is now explicit. We seem to have somehow referred to this rule without actually defining it.