@qt4cg statuses

This PR:

(a) Adds semantics for xsl:copy and xsl:copy-of when the selected item is a JNode (b) Revises the rules for the shallow-copy built-in mode so it does the right thing when processing a JTree (c) drops the shallow-copy-all built-in mode, which is no longer needed (d) adds some simple examples of recursive-descent processing on JTrees using template rules

Fix #1777

Fix #2693

Closes #2909

The encoding behind JWT or PKCE is called base64url (see RFC 4648, §5), and our languages offer no way to produce or consume it: xs:base64Binary only speaks the standard alphabet with mandatory padding, so every implementation of these protocols hand-rolls translate and replace chains.

Two functions, bin:from-base64url and bin:to-base64url, would close that gap alongside bin:hex, bin:octal and bin:bin, which already cover the other textual octet encodings.

The subtyping rules currently make a distinction between recursive record types (which are necessarily named types) and non-recursive types (which may be named or unnamed). This permeates through to the rules for matching types against instances, which are defined in terms of the subtyping rules.

It's not totally clear which rules apply: for example does 3.3.2.9 [Subtyping Non-recursive Record Types] only apply when both types are non-recursive? What are the rules when one type is recursive and the other is not?

In addition it seems awkward, and likely to lead to confusion, if the rules are different depending on whether the definition is recursive: one can imagine this changing over time as the type is refined, and being recursive is a property that may not immediately be apparent to the reader when the chain of references is long.

I think we may get more consistent and predictable results if we draw the distinction between named and unnamed record types, rather than between recursive and non-recursive types (so non-recursive named types behave like recursive named types, minus the recursion). We can then use "named typing" for named types, and "structural typing" for unnamed types.

• For named record types the identity of a type is essentially its name (modulo rules that allow the same name to be used for different types in different modules). Rules for "instance of" and "subtype of" are then based on type names: a record is an instance of a named record type if it is annotated with that type name, and one named record type is a subtype of another if it is explicitly defined as such.

• For unnamed record types, the identity of a type is essentially its definition, and "instance of" and "subtype of" relationships are determined by comparing structure.

• A named record type can then be defined to be a subtype of the corresponding unnamed type (it imposes an additional constraint on instances, namely that the type name must match).

But I'm inclined to be more radical: eliminate unnamed record types. It's probably good software engineering practice (DRY principles) to define types once and give them a name that reflects their semantic purpose, and it certainly simplifies the rules.

Closes #2906

I met with resistance while trying to popularize +:= among users: the plus character implies that something is added, not replaced, and 3 special characters seem over the top.

What about the keyword put?

let $coord as record(x, y, z) := { 'x': 1, 'y': 2, 'z': 0 }
return $coord put { 'x': 0, 'y': 0 }

…like this?

Closes #2900

Fix #2902

Rename the option "trusted" on fn:document to "trust-external", to align with fn:doc.

Also updates some of the relevant change metadata.

Closes #2901

The "trusted" option of fn:document (in XSLT) needs to be renamed "trust-external" for alignment with the fn:doc function

F+O §14.6.5, "Structure of the conversion plan" makes some statements using "must" (without special markup), for example

the corresponding value must be of type fn:attribute-conversion-plan-record

and makes other statements of the form:

The layout entry is always non-empty.

It's not clear how violations of these constraints are to be handled. There's a general rule:

Any error in the conversion plan is treated as a type error [err:XPTY0004]XP

But it's not 100% clear whether violations of these constraints are errors in this sense; and this is particularly true when there is a fallback layout.

There are two cases where non-conformance with the rules is explicitly tolerated:

Any entries whose keys are not in this format will be ignored.

If additional entries (beyond those described above) are present in any of the maps, they are ignored, provided that the map is coercible to the given type definition.

Does "entries (beyond those described above)" include entries that violate the rules described above, and thus imply that entries violating the rules should be ignored?

Clarification is needed.

I know this has been raised before, but I can't find an open issue on it.

In the rules for coercing a map to a record type, the Notes say:

But if the supplied value is { "latitude": 53.2, "longitude": 0, "altitude": 3_500 }, then a type error occurs because the field "altitude" is not defined in the record type.

However, there is nothing in the normative rules to justify this.

In my view we should retain the rules as they are. But I know there is an alternative view that coercion should fail if the map contains excess entries. Either view is workable; they have different pros and cons. I'm inclined to the current rules partly because they are easier to specify, easier and more efficient to implement. However, now that users have the option of casting the map to the record type (which does drop unwanted entries), there's a workaround when that's the behaviour that users want.

Fix #2898

The text currently says:

If evaluation of E fails with a dynamic error, the castable expression as a whole fails.

We should clarify:

• If the target type does not conform to the grammar, static error XPST0003 is raised.
• If the target type does not conform to semantic constraints, for example if it is a choice type that is not a generalized atomic type, or if it is given as a QName that does not resolve to any type defined in the static context, then static error XPST0080 is raised.
• E is evaluated with a required type of item()*, so it will never fail with a type error on the grounds that E delivers values of the wrong type. It may however fail with a type error for other reasons: for example if E is 1 + {} it will fail with a type error because a map cannot be used as an operand of +.
• If evaluation of E (given a required type of item()*), fails with a static error, a dynamic error, or a type error (whether detected statically or dynamically), this is raised as an error in the evaluation of the castable expression.
• If any coercions described as part of the semantics of the equivalent cast expression fail, this results in the castable expression returning false. For example this may apply (depending on the target type) if E evaluates to a sequence of two or more items, or if atomization fails, or if the value of E is a JNode whose jvalue is not a singleton map or array.