@qt4cg statuses

The specification says in [22.1 Constructor functions for XML Schema built-in atomic types](https://qt4cg.org/specifications/xpath-functions-40/Overview.html#constructor-functions-for-xsd-types)…

If the value passed to a constructor is not in the lexical space of the datatype to be constructed, and cannot be converted to a value in the value space of the datatype under the rules in this specification, then an dynamic error is raised [err:FORG0001].

…but it is not clear which rules in the specification are meant.

Specifically, I think we should clarify whether query like the following one are supposed to return an error or a duration:

xs:anyURI('P2000Y') => xs:yearMonthDuration()

On all pages: Improve display of Headlines with slightly smaller font-size.

On rule detail pages: The Name of the Grammar is now visible in the back button of the ribbon instead of the H1 which only displays the rule name.

On the right hand side:

• Fix complement character class display.
• Sequence and choice items now are indented if they do not fit on one line
• occurrence indicators always stick to the item they belong to
• use spans to group items and mark any character that is displayed
• dashes in character ranges and the pipes in choices are now also recognized as part of EBNF syntax
• literals are never wrapped into the next line

Updates the schema for XSLT 4.0:

• Adds canonical to xsl:output and xsl:result-document
• Adds xsl:package-location to content model of xsl:use-package.

I'm suggesting two minor changes following my reading of the most recent draft specs.

This doesn't actually abolish the feature, it just de-emphasises it. AFAIK, no-one actually uses it.

There was pushback on issue #573 which proposed a set of functions for constructing nodes, on the grounds that for XQuery users, this was unnecessary duplication.

A possible alternative is to add a subset of the XQuery syntax for node construction to XPath: specifically, computed node constructors, which are relatively free of hassles such as dependence on the namespace context, boundary space rules, etc.

Specifically we could add computed constructors:

ComputedConstructor::=CompDocConstructor
|  CompElemConstructor
|  CompAttrConstructor
|  CompNamespaceConstructor
|  CompTextConstructor
|  CompCommentConstructor
|  CompPIConstructorCompDocConstructor::="document" EnclosedExpr
 CompElemConstructor::="element"  CompNodeName EnclosedContentExpr
 CompAttrConstructor::="attribute"  CompNodeName EnclosedExpr
 CompNamespaceConstructor::="namespace"  CompNodeNCName EnclosedExpr
 CompTextConstructor::="text"  EnclosedExpr
 CompCommentConstructor::="comment"  EnclosedExpr
 CompPIConstructor::="processing-instruction"  CompNodeNCName EnclosedExpr

with the restriction that CompNodeName / CompNodeNCName are either expressions in curly braces, or use the new XQuery 4.0 form with a leading "#".

It is of course trivial to define a function library on top of this if someone wants the extra flexibility:

let $new-element := fn($name, $content) { element {$name} {$content} }

etc

(Incidentally, EnclosedContentExpr serves no useful purpose as it's identical to EnclosedExpr.)

We could common up the rules for "constructing simple content" and "constructing complex content" at the same time, putting them in XPath where both XQuery and XSLT can refer to them. I believe they are identical except for (a) error codes, (b) with duplicate attribute names, XQuery throws an error while XSLT takes the last.

Fixes nearly everything in #2408

Since we link to pull requests in the spec and in test cases, I wonder whether it would be possible to publish a permanent diff showing the effect of each PR?

Essentially, the idea would be to take the HTML diff as we currently publish it, and reduce it to those sections of the specs that actually contain changes.

I would find this very useful, for example, when a PR has been accepted but is still marked with "Tests needed" - it's not easy at present to see retrospectively what tests might be required. It would also be useful, of course, when implementing the PR. But I think that all readers of the specs might find this beneficial.

Building on the awesome work from @ndw I just tweaked the grammar explorer layout a little more

• layout works better on bigger and smaller screens
• consistent navigation between all screens with back button alwasy on the navigation at the top
• consistent sizes, paddings, colors set by CSS variables
• output as html5 which fixes small issues with whitespace in inline elements
• additional, minor layout improvmements

Before

After

Fix #2421

XSLT Section 3.11 describes embedded stylesheet modules - a stylesheet rooted at an element node which is not the outermost element of a document. There are no real conformance requirements associated with this feature and it isn't widely used. I proposed we drop the section, while retaining the statement in §3.5 that a stylesheet module can be "all or part" of an XML document.

Simplified stylesheets have changed so that the implicit template rule now does match="." rather than match="/".

This creates a theoretical incompatibility when

(a) the stylesheet is invoked supplying a node other than a document node as the input. It will now execute the (only) template rule, previously it would execute the built-in template for the node kind

(b) the simplified stylesheet module is included/imported into another stylesheet. This is a highly unlikely scenario, but it is tested by test case include-0601.

The incompatibility should be documented.

h/t @line-o

Plus a few other tweaks.

Fix #2292

Fix #2399

Fix #2399

Fix #2406

There seem to be two consistent errors in the diff markup that appears in PRs on the dashboard:

1. When an inline <code> element is modified, the diff version shows the old code as deleted (red background), but does not show the new code.

For example:

2. When a grammar entry is modified, the text gets duplicated.

For example:

This PR drops the concept of extensible record types, replacing it with a rule that coercion to a record type drops any map entries that are not defined by the record type. In effect this means that a record type used when declaring a function parameter is implicitly extensible.

The benefits of the proposal are:

• It simplifies the spec, especially rules on type subsumption and on generation of implicit constructor functions
• It avoids the need to declare pairs of record types, one extensible and one not.
• It avoids all the awkward decisions about whether record types used in core functions should be extensible or not.

The rules for type patterns in XSLT are changed to invoke coercion.

Fix #1484 Fix #2365

Fix #2395 Fix #2396

Fix #2397

Fix #2398