@qt4cg statuses

A function for detecting/inferring the encoding from an octet sequence may be helpful:

1. The encoding can be derived from an initial BOM.
2. In addition, implementation-defined heuristics could be used, as e.g. provided by the ICU CharsetDetector.detectAll method.

Norm’s proposal for the function signature:

fn:inferred-encoding($data as (xs:hexBinary|xs:base64Binary),
                     $default-encoding as xs:string? := ()) as xs:string?

We could allow a result sequence and include confidence values in the result.

See the discussion in https://github.com/qt4cg/qtspecs/pull/2222.

Closes #2221

Note that this PR is also a revision of #1950, which I felt was a bit ambiguous, and did not cover all possible cases. I believe that the proposed changes are compatible with 3.1. In particular, it states more clearly what is going to happen if both an implicit encoding is determined (for example, via a BOM), and an explicit encoding is supplied.

This PR is intended to complement PR #2224 by recognising in the XDM specification that the base URI property of a document or element node may be either a URI, or absent, or invalid.

This PR introduces the notion of deferred evaluation and presents the tool to achieve this - the built-in named record type f:generator.

• Two major use cases are presented.
• The fields of f:generator are defined.
• All system-provided methods of f:generator are defined.
• Examples of using each of the methods of f:generator are provided.
• The formal equivalents of each of the system-provided methods of f:generator are provided in a separate appendix.

Fix #2233

I’ve reviewed the unassigned action:

QT4CG-116-01: Add a specific error code for unsupported options on doc and doc-available

I believe that it was intended for MK and I don’t believe that it’s been completed.

The action appears to have been to add a specific error code for the case where options are requested on fn:doc or fn:doc-available that the processor cannot support. For example, if xinclude is true() but the processor is incapable of doing XInclude processing.

I'm creating an issue to track this because it's not entirely clear from the minutes how much consensus there was for this action.

I think the bibliographic reference in

<p>The following types, which were originally defined in
<bibref ref="xpath-datamodel-30"/> and were subsequently adopted by
<bibref ref="xmlschema11-2"/>:
<code>xs:anyAtomicType</code>, <code>xs:dayTimeDuration</code>,
<code>xs:yearMonthDuration</code>.
</p>

Really should be to the 3.0 specification, not the current 4.0 specification. I've fixed that, but left in the bibliographic reference to the current spec.