QT4 CG Dashboard

To follow: options for collection() and uri-collection().

• specifications/xpath-functions-40/src/function-catalog.xml

Add error condition. Fix #1902 I also did some work on removing errors and warnings from the EXPath binary build. There are a couple of outstanding issues I'm not sure how to fix: (a) The function bin:bin had the incorrect id value func-bin-binary instead of func-bin-bin. I've corrected it, but the database of section ids needs updating. (b) In database.xml, the EXPath binary spec is identified as document-summary/@uri = "https://qt4cg.org/specifications/EXPath/binary-40/". But the actual location of the specification is "https://qt4cg.org/specifications/expath-binary-40/" (c) There are tags such as `<code>bin:index-of-range</code>` which the stylesheet is trying to interpret as function names rather than error codes. They actually refer to obsolete error codes so we can't use `<errorref>`

• specifications/EXPath/binary/src/binary-functions.xml
• specifications/EXPath/binary/src/function-catalog.xml
• specifications/xquery-40/src/query-prolog.xml
• style/xmlspec-2016.xsl

Fix #1520

• specifications/xquery-40/src/query-prolog.xml

The PR drops the "uniform" option of `elements-to-maps` into a separate function `elements-to-maps-conversion-plan`, which can be used to analyze a corpus of data and generate a conversion plan for use by `elements-to-maps`. This is useful when the conversion is to be applied to documents that are not part of the corpus, for example when new documents arrive for conversion every day and need to be converted in a consistent way. It also provides a more general mechanism for users to override the system decisions on what layouts to use for what elements. The PR is not entirely complete at this stage: the technical detail is all there, but examples need to be reviewed. Comments are welcome at this stage. There are a few other minor changes. The most notable are: - More consistent fallback when an inappropriate layout is chosen. If the layout does not allow attributes, then attributes are discarded; if there is any other mismatch, the converter falls back to serialized XML layout. - Better handling of boolean and numeric element and attribute content.

• specifications/xpath-functions-40/src/function-catalog.xml
• specifications/xpath-functions-40/src/xpath-functions.xml

Update the table and explanatory notes. Fix #1832

• specifications/xquery-40/src/ebnf.xml

Issue #1363 generated a large amount of discussion on how to handle absent keys in map:get() and out-of-range indexes in array:get(). I felt that one of the simplest proposals was to change the $fallback argument to be a simple default value, rather than a function. This eliminates some of the more "clever" use cases, but these can always be achieved in other ways, as the discussion thread demonstrates. Meanwhile reducing `$fallback` to a simple default value makes life easier for the 90% of cases where this is all that is needed (especially for arrays, when the desire is to return a default value rather than throwing an error). This PR therefore implements that simple proposal. Fix #1363

• specifications/xpath-functions-40/src/function-catalog.xml

Fix #1624

• specifications/xquery-40/src/expressions.xml

Fix #1876

• specifications/xpath-functions-40/src/function-catalog.xml

Supplies rules for how `fn:function-identity()` should handle maps and arrays. Also makes the point that labels are ignored. There's a general statement to the effect in XDM that labels are ignored except where otherwise specified, but it's useful to avoid any doubt here. Fix #1881

• specifications/xpath-datamodel-40/src/xpath-datamodel.xml
• specifications/xpath-functions-40/src/function-catalog.xml

Re-submitted the same as PR 1890. Added some new examples to fn:chain.

• specifications/xpath-functions-40/src/function-catalog.xml

First draft, for initial feedback. Notes: - Because the CG has little energy/resources to develop the EXPath Zip module, I have situated the question of archive (compressed or not) in the URI scheme itself. There are dozens of archives, dozens of URI schemes. The only case where I have found overlap is in the `jar:` scheme/archive. Yes, I've seen `zip:` used as an alias for `jar:`, but it's not an official IANA URI scheme. This may need discussion. - I have opted to bind `@priority` to a non-zero integer. This is the first time the constraint for the union of positive and negative integers has been placed on an XSLT attribute, so I may not have correctly set up `element-catalog.xml`. - I have opted to not make attribute values `format`, `name`, and `version` as criteria for the priority package location (new term), so that developers can be warned when the package is at odds with the declaration. To make them criteria would mean that inconsistencies between the declaration and the referenced packages would remain undetected. - I adopted the terms "URL" and "entry" based upon the IANA nomenclature for the jar: scheme. - I may have overthought the distinction between archive and non-archive URIs. Feedback is appreciated. - Error code `3000` has been broken up into different possible errors. - Suggestions on the type and number of tests that need to be written for the test suite are welcome.

• specifications/xpath-functions-40/src/xpath-functions.xml
• specifications/xslt-40/src/element-catalog.xml
• specifications/xslt-40/src/xslt.xml

Drops the existing fn:chain function and replaces it with a new fn:compose function. This combines two separate changes: (a) whereas fn:chain applies a sequence of functions to an input, fn:compose returns a composite function that can be used repeatedly with different inputs. (b) the fn:compose function is restricted to arity-1 functions, which leads to a much simpler specification that still handles the vast majority of practical use cases. In particular, note that if the sequence of functions to be applied is statically known, then it can always be written out explicitly; the real use case for this function is when the sequence of functions is constructed dynamically. And in this situation, fn:chain in its current form can easily fail because of problems with the arity of the functions included in the chain.

• specifications/xpath-functions-40/src/function-catalog.xml
• specifications/xpath-functions-40/src/xpath-functions.xml

Fix #451

• specifications/xslt-40/src/element-catalog.xml
• specifications/xslt-40/src/xslt.xml

Adds the function `fn:binary-resource` Also fixes some inconstencies in the handling of static/executable base URI in other resource access functions. Fix #557

• specifications/xpath-functions-40/src/fos.xsd
• specifications/xpath-functions-40/src/function-catalog.xml
• specifications/xpath-functions-40/src/xpath-functions.xml
• specifications/xquery-40/src/expressions.xml

This PR is the result of splitting PR #832 into two parts; this part extracts update expressions into a separate proposal, for ease of review.

• specifications/grammar-40/xpath-grammar.xml
• specifications/xquery-40/src/expressions.xml

This proposal is an amended/alternative proposal for the fn:ranks function, taking into account the work done on the original issue #150 and the PR #1027 and the comments raised. Acknowledgements to the original author for the idea and for a lot of good work on examples etc. It amends the previous proposal as follows: (a) the signature and the semantics are aligned with fn:sort. This adds some functionality (multiple sort keys, ascending/descending) and also removes some complexity (two different collations for comparing input items and result items) (b) the style of exposition is changed editorially for consistency with other functions

• specifications/xpath-functions-40/src/function-catalog.xml
• specifications/xpath-functions-40/src/xpath-functions.xml