@qt4cg statuses

Due to fn:sequence-join being re-renamed (#2329), I suggest reverting array:join and dropping the $separator parameter.

Fix #1011

I dropped the idea of adding options for validating the source document prior to transformation -- it got too complicated.

Explains briefly why 1972-01-01 was chosen

Fix #2340

Fix #2343

Fix #2299 Supersedes PR #2309

Allow an arrow expression in a path expression (and, by implication, in a simple map expression):

$x => B() / foo ! bar => C() ! baz / quz

This implementation does not change the relative precedence of / and !.

In this implementation we divide UnaryExpr to SignedUnaryExpr (always with a leading unary sign) and UnsignedUnaryExpr (always without a leading unary sign). And the new feature is supported only in the latter case, since in the former case we cannot avoid ambiguity:

• an expression - aaa => B() / ccc => D() can be parsed both:
  • as (- aaa ) => B() / ccc => D()
  • and as - ( aaa => B() / ccc ) => D()
  • because aaa => B() is the left-hand side operand of /; see also a comment.

I was surprised to find the following rule in the serialiation spec for the html method:

The HTML output method must terminate processing instructions with > rather than ?>. It is a serialization error [err:SERE0015] to use the HTML output method when > appears within a processing instruction in input tree.

I could not find equivalent rules in other HTML specs. For example, the DOM Parsing and Serialization says in 3.2.1.7 XML serializing a ProcessingInstruction node:

Let markup be the concatenation of the following, in the order listed:

1. "<?" (U+003C LESS-THAN SIGN, U+003F QUESTION MARK);
2. The value of node's target;
3. " " (U+0020 SPACE);
4. The value of node's data;
5. "?>" (U+003F QUESTION MARK, U+003E GREATER-THAN SIGN).

Are there specific reasons for omitting the last question mark?

Next, what about whitespace if the value is missing? The test Serialization-xhtml-58 implies that the space character should be discarded if the xhtml output method is used. Does this also apply to html, or is it up to the implementation?

The spec for format-integer says nothing about how to format negative integers. None of the examples are negative. There are test cases that do the obvious thing by prepending a minus sign. But it's not necessarily obvious what the right answer is with a radix other than ten, or with a format such as a or i or w.

I propose that we specify using a leading - regardless of the format and regardless of the radix. If the user wants "minus one" it's easy enough to get it programmatically.

(I was actually looking for a way to force a leading + sign. There's no such mechanism, and I'm not proposing to add it.)

Expands the rules and notes regarding canonical JSON serialization

Fix #2341

Our specification says:

The [serializer] must serialize the normalized sequence according to [[RFC8785]].

RFC8785, however, states that the input to serialization is constrained to conform to I‑JSON [[RFC7493]; we say nothing about how you get from a "normalized sequence" to an I-JSON instance.

And in any case, the JSON output method does not perform sequence normalization, so it's not even clear that there is a normalized sequence to start with. What we actually start with is an arbitrary XDM value.

Many of the answers as to how we get from an arbitrary XDM value to an I-JSON instance are implicit in the introductory section of chapter 9, but extracting the answers requires a lot of reading between the lines.

The main gap in practice is the handling of numerics.

In fact, there's a gap here between the two RFCs. RFC 8785 tells us precisely how to serialize an IEEE 754 (xs:double) value, but I-JSON is a profile of JSON, and therefore represents numbers as a string representation. Neither specification seems to give precise rules for getting from the string representation to the IEEE 754 value. This need not concern us too much, because we're typically starting from an xs:double. But we do need to say what happens if you start with a numeric value other than an xs:double.

The current rules say:

Any absent components, other than the timezone, are substituted with the corresponding components of the (arbitrary) xs:dateTime value 1972-01-01T00:00:00 to produce an xs:dateTime value.

Was it meant to be the UNIX time 1970-01-01T00:00:00? If it is arbitrary, is there a particular reason that we propose a specific constant in the spec?

We don't give a specific rule for the default priority of an element or attribute test containing a NameTestUnion. It therefore defaults to +0.5, which isn't particularly clever as element(A|B) is less specific than element(A).

I think the priority of element(A|B) should be the same as the equivalent pattern element(A) | element(B), namely 0 (zero).

In the grammar, consider

• changing node() to mean "any GNode, that is, an XNode or JNode"
• dropping the syntax gnode()
• introducing xnode() to mean "any XNode".

In the specification prose, consider replacing node by XNode throughout (where this is the intended meaning).