@qt4cg statuses

Fix #2624

Fix #2625

fn:substring takes xs:double arguments for historic reasons; there were some fancy coding tricks you could play in XPath 1.0 by supplying INF or NaN. Today it would make more sense to make the argument xs:integer, especially as coercion will now convert a supplied double to xs:integer.

fn:subsequence was designed along the same pattern and in 2.0, 3.0, and 3.1 it expected xs:double for its arguments. But in issue #2542 and PR #2543 we changed the argument type to xs:numeric.

I can't see any good reason why we shouldn't make the same change to fn:substring.

I propose that we drop error codes XPTY0019 and XPTY0020 in favour of XPTY0004.

Firstly, there's a big overlap between XPTY0019 and XPTY0020: with a path expression such as $x/child::node(), if $x selects items that aren't nodes, it's perfectly legitimate to raise either. Furthermore, the rule in §2.4.3.2

If an operand of an expression does not have a [dynamic type] that is a [subtype] of the [static type] required for that operand, a [type error] is raised [err:XPTY0004]

would legitimise XPTY0004 for this situation.

We state in §4.7.5 Axis Steps: "The [axis step] S is equivalent to ./S", but that isn't true because the error codes are different.

It's unlikely that anyone would use try/catch to catch either XPTY0019 or XPTY0020, firstly because of the overlap, and secondly because type errors will often be raised statically.

Fix #2621

Fix #2612

In https://qt4cg.org/specifications/xpath-functions-40/Overview.html#func-transform , post-process is one of the options listed under "The meanings of each option are defined in the table below." Should it also appear earlier in the document, in the "Zero or more of the following additional options:" lists?

Adopted from #2408:

• [ ] Reference bin:infer-encoding, drop redundant rules

Triggered by https://github.com/qt4cg/qt4tests/pull/372#issuecomment-4394361787 and previous observations:

• [ ] Merge FOUT1190 and FOUT1200

In F&O, the tabulation of options for functions taking an options parameter uses the obsolete notation where a field name is followed by a ? to indicate that it may be absent.

The convention for options parameters is that supplying an empty value is the same as omitting the entry; but the tabulation often doesn't indicate that an empty value is acceptable.

In the operator mapping table for arithmetic operations that multiply or divide a duration by a number, the second operand is described as xs:numeric, but in the signature of the corresponding op: functions in F+O, it is listed as xs:double. This implies for example that with an expression such as xs:dayTimeDuration('PT1H') * 1.2, we have to convert the decimal 1.2 to a double, delivering a result that is not quite equal to PT1H12M. We could remove the anomaly by changing the signature to use xs:numeric.

At the same time we can remove the restriction that the first operand has to be xs:dayTimeDuration or xs:yearMonthDuration. It's perfectly possible to apply the operation to any xs:duration - just multiply or divide the months and seconds components individually and combine the results.

Following the discussion of PR #2614 (which was accepted), this PR provides additional notes, clarifications, and examples.

The only substantive change is to deal with the case where the xsl:array-member instruction inadvertently selects JNodes; it avoids double-wrapping these in further JNodes.