@qt4cg statuses

The now-merged PR #2966 has introduced inconsistency to the specifications.

The prefatory prose for 6.1.8 invokes the concept of "current position" and that concept is at the heart of the definitions of boundary assertions and all lookahead and lookbehind assertions, but it is no longer part of the definition of metacharacters ^ and $. Either the latter should be redefined in terms of current position, or the other assertions should be redefined without reference to current position, and the initial prose about assertions should be revised to drop any reference to "current position".

The functions upper-case() and lower-case() are defined by reference to the Unicode standard, but it is not easy to locate the specific rules that are being referred to, partly because we don't provide a precise link, and partly because the terminology seems to have evolved. We also need a clearer indication (and recognition in the test suite) of how changes between Unicode versions should be handled.

Also we might want to consider the way in which case-blind matching (the 'i' flag in regular expressions) is defined. This allows a lower-case character to match only one upper-case character, and vice versa.

There are some new test cases that have been submitted (e.g. caselessmatch17/18/19) that illustrate the difficulties.

…later than “next minutes”, but it’s online now. Closes #2980

As indicated before, the adaptive output method tries to serve two purposes at once, and it achieves neither reliably:

1. Output that can be pasted back into a query. The spec calls this “an aim rather than a requirement”. In practice, the output often fails to parse or doesn’t give back the same value.
2. Human-readable output for debugging. Here the method is more verbose than it needs to be.

As a result, implementations tend to do some magic on their own. In, BaseX, for example, we added a custom basex method.

In the past, I have introduced some half-baked extensions to the serialization methods, like #2389, and I think we should go one step further. I propose to add a new serialization parameter, adaptive-mode, with two values:

• expression (default): the output is an expression in the host language that rebuilds the value as far as possible. It stays close to today’s output, with stricter rules.
• readable: values are shown by their content, e.g. 2015-07-17 and true. Only kinds that would otherwise be unrecognizable are marked, such as JNodes and QNames. This mode suits console output, logs, and (depending on the implementation’s preference, fn:trace and fn:message).

This PR simplifies the definition of record types as follows:

1. Terminology: structural and nominative record types become "simple" and "labeled" record types
2. Simple record types revert to being purely structural: both type membership (matching) and subtyping depend only on comparing the contents of the definitions; no type annotations are needed on map instances.
3. The default for the %constructor annotation switches; you now need a %no-constructor annotation to prevent the generation of a constructor function.

…an attempt to simplify records, as motivated by the table in https://github.com/qt4cg/qtspecs/issues/2972#issuecomment-6096543708. All kind of feedback is welcome (much more time went into this than originally planned; it also includes cleanups of minor inconsistencies).

The good thing: it made the implementation much easier again.

Closes #2972

👋

Now that we have revised the dot semantics (.) in parameter default values, I believe that fn:current is not needed in XQuery anymore: current does not tell what it does, and for XSLT users, it may simply be confusing because it behaves differently.

In the upcoming PR, I’ll revert #2867.