@qt4cg statuses

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.

Add a new function signatures

fn:collection($source as xs:string := (), $options as map(*)? (:default-on-empty:) ) as item()*

fn:uri-collection($source as xs:string := (), $options as map(*)? (:default-on-empty:) ) as xs:string*

similar to the newly added functions in XQuery 4.0 adding options parameters to existing functions like fn:doc#2.

For collection and uri-collection I see the following:

• recurse: traverse collection trees down into its subcollections
• stable: this is already vaguely mentioned in the spec and would benefit from a clearer specification
• type: (aka media-type or content-type) while the allowed values will be implementation defined the key should be standardised

This is a follow-up to https://github.com/qt4cg/qtspecs/issues/1021

• Deleting err:FODT0006
• Updating the information about errors thrown by fn:build-dateTime
• No change to the text for fn:parts-of-dateTime, as it doesn't currently include a section on errors. This is consistent with the current expectation that neither fn:parts-of-dateTime nor the implicit constructor for fn:dateTime-record will check that the values supplied represent a valid date/time datatype.

As outlined in issue #2568, this represents a proposal to drop err:FODT0006, which is currently only expected to be thrown by fn:build-dateTime.

Like the functions for extracting components of dates and times, fn:build-dateTime essentially orchestrates casting from one date/time-related datatype to another date/time-related datatype; determining which standard date/time constructor needs to be used and supplying the relevant arguments. The errors thrown by date/time constructors are already defined: most commonly err:FORG0001 but also err:FODT0003 for an out-of-range timezone value. My suggestion is that, as with the functions for extracting components of dates and times, there is no need for an error code specific to fn:build-dateTime.

err:FODT0005 would remain unchanged and still be thrown by fn:build-dateTime if the combination of arguments supplied can't be mapped to a date/time datatype.

Add a regex($pattern, $flags) function to construct a "compiled" regular expression. This gives a clear signal that the same regular expression might be used repeatedly; it avoids relying on caching, which can be unnecessarily expensive and is not predictable across implementations.

Two possible ways this might work:

(a) allow the result of the regex() function to be used as an argument to functions such as matches(), tokenize(), etc, in place of the $pattern and $flags arguments

(b) make the regex() function return a record with methods matches(), tokenize(), replace() etc whose functionality corresponds to the existing functions.

The second approach seems easier to fit into the type system. With the first approach, it's unclear what kind of value the regex() function should return.

Some of the syntax scraps in the XSLT spec recurse much too deeply, see for example 6.3.2.1 Predicate Patterns

In the XPath/XQuery specs, the expansion stops when a construct is reached whose name appears at the head of its own scrap. This doesn't work for XSLT patterns because the expansion is in a different spec.

Fix #2580

Edits here were motivated by several points that caused me confusion tonight:

• 4.1.2 and 4.1.5 had duplicate text, an indication that they belong next to each other.
• In 4.1.2 there were no pointers to the definitions of the datatypes discussed.
• The fifth bullet point in 4.1.2 is not a schema type (which is the topic of the unordered list). The material belongs outside the list.
• The fifth bullet point claims that XDM defines two data types, but it doesn't. And it doesn't mention another data type discussed in predefined data types.
• There is a long discussion of xs:error in the XPath specs, but the reader of this section has no clue on where xs:error is defined or explained.

Etc. I suspect my draft here still has problems, but I hope it's an improvement.