QT4 CG Dashboard

This proposal has two ingredients (a) a single function generate-sequence() that produces a sequence of states from an initial state and a function that computes one state from the previous state (b) a definition of pipelining (aka lazy evaluation) and (currently incomplete) rules requiring certain operations to have a pipelined implementation.

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

Fix #1011 I dropped the idea of adding options for validating the source document prior to transformation -- it got too complicated.

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

Fix #2299 Supersedes PR #2309 Allow an arrow expression in a path expression (and, by implication, in a simple map expression): ```xquery $x => B() / foo ! bar => C() ! baz / quz ``` This implementation does not change the relative precedence of `/` and `!`. --- In this implementation we divide `UnaryExpr` to `SignedUnaryExpr` (always with a leading unary sign) and `UnsignedUnaryExpr` (always without a leading unary sign). And the new feature is supported only in the latter case, since in the former case we cannot avoid ambiguity: - an expression `- aaa => B() / ccc => D()` can be parsed both: - as `(- aaa ) => B() / ccc => D()` - and as `- ( aaa => B() / ccc ) => D()` - because `aaa => B() ` is the left-hand side operand of `/`; see also a [comment](https://github.com/qt4cg/qtspecs/issues/2299#issuecomment-3544885512).

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

Fix #2297 Fix #2330 Fix #2334 Fix #2335 Fix #2339 This PR changes the syntax and semantics of JNode types, tests, and patterns, bringing them closer into line with each other and with the corresponding constructs for XNodes. It also fixes problems of grammar ambiguity. JNode types are revised to take the form `jnode(selector-value, content-type)`, mirroring the syntax of element and attribute types, and bringing them into line with JNode patterns. This also enables JNode patterns to be integrated with XNode patterns, using common syntax and semantics. Subtyping rules for JNode types are added. When types are used for selection in a JTree, the type must now be a JNode type, not the content type. For example, in place of `$array/map(*)`, you need to write `$array/jnode(*, map(*))`. While more verbose, this syntax is more consistent with selection in XTrees, and is more powerful. (It also offers potential extensibility to eliminate the `get(X)` construct). In XSLT patterns, union/except/intersect (and parenthesized patterns) now apply only to node patterns (reverting a 4.0 enhancement which caused parsing difficulties). The semantics of except and intersect have also reverted to the 3.0 semantics. The semantics of patterns has become closer to the semantics of the corresponding XPath expression, insofar as patterns such as `doc` or `*` can now match either an XNode (specifically an element) or a JNode. It is no longer necessary to use the explicit syntax `match="jnode(doc)"` or `match="jnode(*)"`. XSLT type patterns are now uniformly written `~ItemType`, rather than using the bare item type in some cases (such as record types), and the more verbose syntax `type(ItemType)` in other cases. This avoids conflict with the use of `type(x)` in path expressions.

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

@michaelhkay I have decided to create this PR, even if we are still discussing its necessity. I hope it clarifies where I see the need for unifications in the current presentation. In general, it follows the proposal that I developed in my thoughts in #2298. In particular, it fixes various small inconsistencies in the prose. I have stumbled upon related editorial issues that I haven’t worked at yet: [1.6 Function calls](https://qt4cg.org/specifications/xpath-functions-40/Overview.html#id-function-calls) is outdated, for example the `fn:function-name` (which could be confused with the actually existing function with the same name) should have an optional parameter. Next, the text talks about “two signatures of `fn:string`”; and it is not clear why the “zero or one values” and “zero or more values” cases are presented in more detail, whereas “one or more” is missing. The reason is probably simple: It seems to stem back to version 3.1. Closes #2298

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

Fix #407

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

Meets the requirement by adding magic environment variable names to fn:environment-variables.

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

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. <img width="1920" height="1080" alt="image" src="https://github.com/user-attachments/assets/65d04952-794f-4a81-ae64-c96217a9812d" />

• schema/xsl-query.dtd
• specifications/xpath-functions-40/src/function-catalog.xml
• specifications/xpath-functions-40/src/xpath-functions.xml

This is a first draft of a PR, giving the data model changes only, for a change to the JNode model affecting maps and arrays with sequence-valued entries. A sequence of length 2 or more now has children representing the items in the sequence. Although there is still an asymmetry between sequences of length 1 and longer sequences, it is more manageable than i the previous model.

• specifications/xpath-datamodel-40/src/xpath-datamodel.xml

A first cut at providing a functional approach to XNode and XTree construction. At this stage I'm interested in comments on the general approach, not the fine detail (some of which, e.g. namespace inheritance, still needs work.)

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

Proposes a new fn:update function that can handle both JNodes and XNodes. (this is a branch on a branch, so I don't know how well the diff'ing will work; but look in F&O for the fn:update function)

• specifications/grammar-40/xpath-grammar.xml
• specifications/image-sources/item-types.xml
• specifications/xpath-datamodel-40/src/xpath-datamodel.xml
• specifications/xpath-functions-40/src/function-catalog.xml
• specifications/xpath-functions-40/src/xpath-functions.xml
• specifications/xquery-40/src/expressions.xml
• specifications/xslt-xquery-serialization-40/src/xslt-xquery-serialization.xml

Currently work In progress, committed so that the draft can be reviewed. Changes in three main areas: - Pattern syntax: patterns such as `?item` and `?parent?item` are defined to match items in a map by their key - Built-in template rules for on-no-match="shallow-copy-all". Revisits the built in template rules for this scenario. - General revision of the processing model for xsl:apply-templates applied to a tree of maps and arrays.

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