@qt4cg statuses

Following on from issue #2613 (and PR #2614), should we make xsl:map-entry return a JNode?

This instruction is present in XSLT 3.0, and it is defined to return a single-entry map. The xsl:map instruction expects a sequence of maps as input, and it merges them. It would be easy enough to change xsl:map-entry to return a JNode, and xsl:map to accept that JNode, but there would be a backwards incompatibility for any application that uses the result of xsl:map-entry in any way other than to construct input to xsl:map.

There are in fact two ways we could change xsl:map-entry to return a JNode. We could return a JNode whose jvalue property is a single-entry map, or we could change it so that the jkey property is the relevant key and the jvalue property is the corresponding value.

We need to examine what the benefits of making this change would be, especially when it comes to doing "shallow-copy" template-based transformations of a tree of maps and arrays.

Fix #2613

xsl:array-member returns a "parcelled" value that is subsequently used by xsl:array to form a mamber of an array. The parcelled value is currently represented as a zero-arity function.

I propose to change this so the result is represented as a JNode.

The disadvantage of the current approach is that the representation used by xsl:array-member doesn't correspond to the representation used by any of the standard mechanisms used for decomposing an array into its members. So it's fine for constructing a brand-new array, but not for operations like adding or removing members to an existing array. This makes it hard to find a good way of transforming arrays using template rules.

With this change, we would be able to do something like

<xsl:variable name="$array" select="parse-json($cities)/*"/>
<xsl:variable name="$subarray" as="array(map(*))>
   <xsl:array>
      <xsl:sequence select="$array[?country='UK']"/>
      <xsl:array-member select="{'name': 'Douglas', 'country': 'Isle of Man'}"/>
   </xsl:array>
</xsl:variable>

to construct an array that combines members selected from an existing array with newly constructed members,

The basic changes are:

• xsl:array-member returns a parentless JNode that encapsulates the selected value.
• xsl:array takes a sequence of items. Each item becomes one member of the array. If the item is a JNode, it is unwrapped to use its jvalue property. The jkey and jparent and jposition properties are ignored.

This then raises the question of whether we should do the same for xsl:map and xsl:map-entry. Symmetry suggests we should. But there are a couple of complications: firstly, we have to think about backwards compatibility, since xsl:map-entry is present in XSLT 3.0. Secondly, the JNode produced by xsl:map-entry would have a key but no parent, which is a novelty in terms of the current data model, and we would need to reassure ourselves that this has no unintended consequences.

The JSON parser detects the backslash-escape sequences \b for backspace and \f for form feed. With the extension to XML 1.1, we should probably also allow these for fn:char.

Some more escape sequences exist for beep et al. (https://en.wikipedia.org/wiki/Escape_sequences_in_C), but they may raise more questions than giving answers.

Fix #2598

Fix #2584

I've tried to incorporate feedback from the discussion, though my notes and the official minutes fail to capture all the points that were made.

Closes #2312

Closes #2314

Closes #2605

The current spec for file:copy and file:move does not address the case where $source is a directory and $target is located inside it. A naive implementation of the recursive rules can enter an infinite loop or even corrupt the file system.

Example:

file:copy("/data/foo", "/data/foo/bar")
file:move("/data/foo", "/data/foo/bar")

I'm not quite sure what "markup error" the action was referring to, but I've proof-read the relevant section and fixed a couple of typos.

Fix #2602.

The EXPath file and binary modules become optional conformance features in XQuery and XSLT.

Interrogatives for these features are added to the system-property() and system-properties() functions.

Fulfils action QT4CG-158-02

I propose to define support for these libraries as "optional features" in the conformance rules for XQuery 4.0 and XSLT 4.0.

Replaces https://github.com/qt4cg/qtspecs/pull/2599 to fix #2568

Error code FODT0006 is retained but reserved only for reporting when the value of hours is 24. This is the only rule that applies to a valid combination of components, that diverges from the existing rules for the date/time constructors.