@qt4cg statuses

The current "?>" method call operator is ugly, difficult to read, difficult to find and understand. We have much better alternatives.

One obvious big improvement is to have ==> .

This is:

1. Readable.
2. Distinctly distinguishable.
3. Understandable and intuitive for anyone who has used an OOP language (C++, C#, Java)
4. Expresses the similarity with the => operator. The same way => provide the LHS item as the first argument of the RHS function, the similar, and extended, in appearance ==> provides the LHS map/object as an implicit argument to the RHS method.
5. Because of 1, 2, 3, and 4 above, very little additional learning and understanding effort is required from the XPath user.

Proposed action: Replace the ugly, difficult to read, difficult to find and understand operator "?>" with ==> .

StringInterpolation currently defines a two-character token, curly right brace + backtick, to follow Expr as a terminator:

StringInterpolation ::= "`{" Expr? "}`"

On other occasions, Expr is followed by a single right curly brace:

EnclosedExpr ::= "{" Expr? "}"

The following applies to tokenization (the "longest-token" rule):

If the current position is not the end of the input, then return the longest literal terminal or variable terminal that can be matched starting at the current position, regardless whether this terminal is valid at this point in the grammar.”

My concern is that input like

<a>{42}`</a>

is going to be mis-tokenized under the longest-token rule: after 42, the next (longest) token is the two-character StringInterpolation terminator, which however is not a valid terminator of the EnclosedExpr serving as CommonContent of the direct element constructor.

Proposed fix

My proposal is to replace the two-character tokens that introduce and terminate StringInterpolation with single backticks around an EnclosedExpr with no intervening whitespace:

StringInterpolation ::= "`" EnclosedExpr "`"   /* ws: explicit */

This replaces both of the two-character delimiters of StringInterpolation, while still describing the intended language, but without causing the longest-token rule to produce a token that cannot be handled afterwards.

Fix #2139

hexBinary and base64Binary become mutually comparable under all comparison operators: which may affect backward compatibility.

Fix #2166

In reverting many of the features previously added to lookup expressions (for example deep lookup and lookup modifiers) we seem to have accidentally lost text that actually defines what the different key specifiers mean; we're left with lots of examples but no actual specification.

I was reading to see what the current spec says about array bound checking: it appears to say nothing.

Related: Michael’s observation in https://github.com/qt4cg/qtspecs/issues/2163#issuecomment-3185618064.

The current spec says for treat:

XPath 4.0 provides an expression called treat that can be used to modify the static type of its operand.

It further mentions the static analysis phase, which has been removed from the specs; maybe we should remove these references.

There are hardly any uses of the expression in the current spec. One is for Absolute Path Expressions:

An expression of the form /PP (that is, a path expression with a leading /) is treated as an abbreviation for the expression self::gnode()/(fn:root(.) treat as (document-node()|jnode())/PP.

The use seems confusing, as in many cases self::gnode() can only be evaluated at runtime. Maybe we could rewrite it to a variant that coerces the node? It would generally be easier for optimizers to rewrite paths when there is no need to differentiate between treat and coercion (and I have never seen code that catches XPDY0050).

Indeed I think it would be helpful to have a coerce to expression, even if people will rarely use it explicitly. It would allow us to remove all remaining uses of treat as (except, of course, for the expression itself), and we could simplify various examples that use variable declarations only for coercing values.

In f2e1f48, fn:parse-csv was changed to return an empty sequence, when its first argument is an empty sequence. This is however not reflected in the function's return type, which is here changed to parsed-csv-structure-record?.

I propose using =?> for method calls rather than ?>

(a) I lilke the association with => to call a function item with an implicit first argument; =?> combines selection of an item from a map (?) with function invocation (=>)

(b) ?>, while technically unambiguous, smells strongly of XML processing instructions

Expands the explanation of the example of method chaining