@qt4cg statuses

An error is raised for an option key unless (a) it is listed in the specification, or (b) it is recognized by the implementation, or (c) it is a QName with a non-absent namespace.

Also clarified the rule about accepting an array in place of a sequence (I'm not sure whether this is something that we actually do, and certainly it doesn't happen unless the parameter explicitly allows an array.)

Fix #1166

To avoid the ugly third parameter to deep-equal which will almost always be set to (), merge $collation into the $options parameter, whose type becomes (map(*) | xs:string)? for backwards compatibility.

The same idea is being applied to unparsed-text and can probably be done elsewhere.

PR #1059 introduced the rule:

If an option is not described in the specification, if it is not supported by the implementation and if its name is in no namespace, a type error [err:FORG0013] must be raised.

and this has proved its worth in finding quite a few errors in the test suite!

However, it's not entirely clear what it means.

Entries in the options map can have keys of any type. I suspect this rule is intended to apply to (a) keys of type xs:string, and (b) strings of type xs:QName where the namespace URI is absent.

Alternatively, perhaps it should apply to ALL option keys other than a QName in a non-null namespace?

A quick glance in F+O finds:

 \n (newline, x0A)
π (x3C0)
the glyph ≂̸ which is expressed using the two codepoints #x2242 #x0338
A format token of ١ (Arabic-Indic digit one)
the format token ① (circled digit one, ①)
the actual Unicode character COMBINING DIARESIS (Unicode codepoint U+0308) or ̈
The Latin small letter dotless i (ı, U+0131, used in Turkish)
the Unicode replacement character (U+FFFD)
CRLF (U+000D, U+000A), LF (U+000A), or CR (U+000D)
comma "," (U+002C)
the Unicode quotation mark " (U+0022)
a single newline (U+000A) character

I feel we could do better...

Use a common style for all glossaries.

Add a glossary to F+O.

Fix #1155

I feel that the decision to change xs:integer to xs:positiveInteger was a bit hasty (https://github.com/qt4cg/qtspecs/pull/1131#issuecomment-2051379262):

To be consistent, numerous other expressions and functions would need to be rewritten as well to use stricter types (arbitrary examples: the count clause; $err:line-number in the catch clause; the result type of fn:string-to-codepoints; positions in array:get, fn:parse-integer, etc.; the position parameter in HOF functions, and so on and on). We haven’t done so yet, and I seriously wonder what exactly we would win from the stricter types. In many cases, it would be reasonable to also define a strict upper limit, which is not possible with our types anyway.

Implementations may build heavily on the fact that xs:integer has been the default type for integer values in previous versions of the languages. For example, we use cached instances for the most small integer values, or we rewrite constructs with xs:integer to other constructs accepting the same type.

For all these challenges, as always, technical solutions exist, but the question is if there aren’t more interesting things to focus on than on such corner cases. Queries like count(1 to 1000000000000) are not supported by all implementations either although they may appear trivial to the ordinary user (by coincidence, it’s supported by BaseX, but I doubt it has been used a lot).

In short, I would like us to revert the change in https://github.com/qt4cg/qtspecs/pull/1131/commits/bba6e4f1067e0ef0779688622a58320a5298d440 and stick with xs:integer. If people feel bad about it, I would suggest discussing strict types in a much broader and general way.

Issue #898 was about dropping this constraint that document-uri()s had to be unique and PR #905 was adopted to resolve it. However, I see that the the XPath specification still contains the following note:

Note:

This means that given a document node $N, the result of fn:doc(fn:document-uri($N)) is $N will always be true, unless fn:document-uri($N) is an empty sequence.

I don't believe that applies any longer, so it should be removed.

It's possible that we need to finesse the description of available documents as well. The current description was clearly written from the perspective that document URIs would be unique and there'd be a 1:1 mapping from URIs to documents.

The new function fn:collation raises an error [err:FOCH0002] in the case when the requested collation is not supported. Or, if the fallback key's value is true(), then the implementation chooses "the most similar supported collation" - which could be perceived as arbitrary and unexpected by the code developer.

This might be OK if the language has try/catch capabilities and fallback="no" is specified, but may not be the best outcome in a pure XPath evaluation.

A solution to this problem is to provide a function fn:is-collation-available that accepts the same argument ($options map) as fn:collation, and also could accept a string argument whose value is the URI of the collation. This function produces a boolean, true() meaning that the collation is available and can be constructed and used, false() - otherwise.

Signature

fn:is-collation-available( $descriptor as xs:string | map(*) ) as xs:boolean