@qt4cg statuses

See #2408

Fix #2527 Fix #2528

Looking at the issues raised by this action I decided to make a couple of changes that are not purely editorial.

• Confirming that an xsl:param in the used package cannot be overridden by an xsl:param or xsl:variable in the using package, because it is private (the 3.0 spec contained conflicting statements here).
• Allowing a non-static xsl:param in the used package to be initialised using a non-static expression in the using package (thus allowing parameter values to be passed through transitively).

Fulfilling the action. Editorial only.

Fulfilling action QT4CG-155-02

The current XQFO draft makes normative reference to RFC 7159 for the definition of the JSON grammar. This spec has been obsoleted by RFC 8259. The CG may want to consider updating this reference.

The new version substantively differs in mandating exclusively mandating UTF-8 for interchange: passages assuming the acceptability of UTF-16 and UTF-32 would need to be changed. The definition of fn:json-doc already goes beyond RFC 7159 by allowing the parser to process any additional charset it wants, so I don't think this really affects anything.

The definition of fn:parse-json says:

The input MUST consist of an optional byte order mark (which is ignored) followed by a string [...]

The wording here is unclear; is the BOM required or optional? Previous CG discussion (https://github.com/qt4cg/qtspecs/issues/1704) indicates the intent to be latter, in which case the definition should be rewritten.

I propose enhancing the item type syntax to allow facets (as in XSD) to be defined for atomic types.

For example

declare item type cal:month as xs:integer with (minInclusive=1, maxInclusive=12);

declare variable $quote-character as xs:string with (minLength=1, maxLength=1) external;

The semantics are exactly as if a restricted type with the same facets were imported from a schema.

At least initially:

• facets are allowed only on atomic types and not on xs:untypedAtomic
• the value of the facet must be a Constant
• we only allow facets that restrict the value space (therefore not whitespace)
• we allow the pattern facet only on xs:string and xs:anyURI so it becomes a restriction on the value space
• we don't allow the enumeration facet (though we could consider using it to replace our current enum type)
• we only allow one value for each facet (so no multiple patterns)
• we drop some of the dubious combinations such as defining length facets on xs:QName.

In the subsumption rules, the atomic type A with (FACETS) is a subtype of A.

The first feedback on JNodes shows that people find the analogy between XML and maps/arrays really attractive. At the same time, it’s perhaps the most challenging part, as the subtle differences of the two data types need to be understood.

For example, our constructors behave differently: Whereas the node constructor includes the full node in the result…

let $xnode := document { <n>123</n> }
return document { $xnode/n },

(: result :)
document { <n>123</n> }

…the map constructor includes only the ·jvalue· and ignores the ·jkey· and, such that the following query fails:

let $jnode := { 'n': 123 }
return { $jnode/n }

Maybe we can tweak map constructors by generating single-entry maps from non-root JNodes?

let $jnode := { 'n': 123 }
return { $jnode/n }

This would enable us to do many other things, such as filtering:

let $jnode := {
  'lu': 'lunes',
  'ma': 'martes',
  'mi': 'miércoles',
  'ju': 'jueves'
}
return { $jnode/(lu, mi) }

(: result :)
{ 'lu': 'lunes', 'mi': 'miércoles' }

In addition, if required, we could introduce an explicit function to convert a JNode to a single-entry map (basically, a shortcut for map:entry(jkey(), jvalue()).

4.3 Lookup Expressions says:

If $V is a JNode then it is coerced to the required type (map(*)|array(*)).

We should change the type to (map(*)|array(*))*. Otherwise, the following expression raises an error:

let $jnode := { 'a': ([ 0 ], [ 0 ]) }/a
return $jnode?1

Origin: https://github.com/qt4cg/qtspecs/pull/2506#discussion_r2900780344

We're currently using @v4 which (apparently) uses a deprecated version of Node.js. Before June, we should upgrade to @v6, but I think I won't do that while I'm on vacation.

This PR started as a fairly local change to resolve issue #2520 (year zero in build-dateTime and parts-of-dateTime) but it gradually became more ambitious.

The data model now states that the definitions of atomic types are taken from XSD 1.1. This means, for example, that xs:date includes year zero, and xs:double includes negative zero. It is still permitted to use an XSD 1.0 processor for schema processing and validation, but other operations (including casting from string) must follow the XSD 1.1 rules.

In the course of this some rules (including the rules on limits) have migrated from the XQuery and XSLT specs into the XDM specification.

Fix #2520

Fragment identifiers are now allowed in fn:doc calls, but they are still illegal in other functions (like fn:unparsed-text), for no apparent reason. We should generally allow them.

While reviewing qt4cg/qt4tests#340, I noticed again that the error codes for fn:unparsed-text are a bit of a mess, and difficult to adhere to when using low-level I/O:

• A dynamic error is raised [err:FOUT1170] if the $source argument contains a fragment identifier, or if it cannot be resolved to an absolute URI (for example, because the base-URI property in the static context is absent), or if it cannot be used to retrieve the string representation of a resource.
• A dynamic error is raised [err:FOUT1190] if the value of the encoding option is not a valid encoding name, if the processor does not support the specified encoding, if the string representation of the retrieved resource contains octets that cannot be decoded into Unicode characters using the specified encoding, or if any resulting character is not a permitted character.
• A dynamic error is raised [err:FOUT1200] if the encoding option is absent and the processor cannot infer the encoding using external information and the actual encoding is not UTF-8.

Things don’t get better with the introduction of the fallback option. I would prefer to see them merged to single error code, preferably FOUT1170, and to simplify the description to…

A dynamic error is raised [err:FOUT1170] if the the string representation of a resource cannot be retrieved.

…or to at least drop FOUT1200 and merge it with FOUT1190.