@qt4cg statuses

In the past, the number-parser option was added to fn:parse-json and fn:json-to-xml. It has been removed from fn:parse-json again (and replaced by number-format), and I think we should also remove it from fn:json-to-xml:

• In the XML representation, the original JSON representation is adopted 1:1, so the result will be lossless (which is why number-format was not introduced for this function). If really needed, it can be changed in a post-processing step.
• It seems much too specific to me, and we don’t have corresponding parser functions for other data types (null, booleans, etc.)

If we keep it, we should fix a typo (“convered”).

Fix #2458

This proposal introduces two changes, which taken together, replace the use of get(expr) in axis steps.

For JNodes, with an expression E1/E2, if E1 selects JNodes and E2 selects atomic values, then the atomic values are matched against the jkey properties of the child JNodes.

More generally, axis::{expr} (for example descendant::{$name} selects nodes on the relevant axis whose name/jkey is equal to the result of evaluating expr.

Fix #2661

Provides an option to element-to-map() to replace the string "#content" with one of the user's choosing.

Fix #2663

Interesting user feedback (two aspects bundled in a single issue, but my weekly issue creation budget is already exhausted):

Shouldn’t the following query work?

<Name>
  <Nachname>Berger</Nachname>, <Vorname>Johann</Vorname>
</Name>

(: XML above as context :)
(: WORKS :) 'Name: ' || string(./Name)
(: FAILS :) 'Name: ' || string(element-to-map(.)/Name)

Observations:

1. We should have a closer look at the atomization of JNodes (concatenate leaf ·jvalue· items?)
2. The input type of fn:element-to-map should be extended to document nodes (in alignment with fn:element-to-map-plan)

Computed node constructors currently have custom rules for type coercion of the results of the expression used to compute the node name. The rules are almost equivalent to the coercion rules for a required type of (xs:QName | xs:string) in the case of elements and attributes, or xs:string in the case of namespaces and processing instructions. But they are slightly different, for example they disallow promotion from xs:anyURI. These distinctions serve no useful purpose and prevent implementations reusing common code.

Closes #2659

I have added three other trivial functions for operations that are cumbersome and inefficient to formulate in XPath: bin:rotate, bin:is-bit-set, bin:sets-bits.