@qt4cg statuses

Fix #2738

Gently improves the introductory sections of the XSLT spec to better reflect the introduction of JTrees and JNodes.

It could do with a more radical overhaul but this is a step in the right direction.

In the XSLT Concepts section and elsewhere, the terms "tree" and "document" are used without saying explicitly whether the terms include or exclude JTrees. Some of the statements that are made about trees are equally applicable to XTrees and JTrees, while others are specific to XTrees. Because the definitions are unclear, the use of these terms throughout the spec is also unclear. This extends to the XSLT Streaming spec.

I would like to propose an idea to introduce context parameters. The goal is to allow to pass parameter in a scope rather than globally or inside of a whole template.

The idea is like this:

<xsl:param name="my-var" as="xs:string" context="yes"/>

or even

<xsl:param name="my-var" as="xs:string" tunnel="yes"/>
...


<xsl:function name="t:my-function" as="xs:string">
...

   <xsl:sequence select="$my-var"/>
</xsl:function>
....

<xsl:context>
  <xsl:with-param name="my-var" select="'123'"/>

   ... do something, e.g.:
   <xsl:sequence select="t:my-function(...)"/>
</xsl:context>

This feature will closely resemble what java and node have with async scoped variables. See https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/lang/ScopedValue.html See https://nodejs.org/api/async_context.html

Reformulates StringInterpolation as proposed and discussed in #2169.

Closes #2169

We should improve the representation of JNodes with the standard xml and json serialization methods. Keys are simply lost in the output, which is particularly troubling for newcomers:

(: query :)
<xml><city>Roma</city><name>Andrea</name></xml>/* ,
{ 'city': 'Roma', 'name': 'Andrea' }/*

(: result :)
<city>Roma</city>
<name>Andrea</name>
Roma
Andrea

My suggestion would be to output (non-root) JNodes as single-entry maps:

{ 'a': 1, 'b': 2 }/*
{ "a": 1 }
{ "b": 2 }

[ 'a', ('b', 'c') ]/*
[ 1: 'a' ]
[ 2: ('b', 'c') ]

An alternative for JNodes that result from arrays could be the representation as a single-member array (XML nodes don’t include indexes either):

[ 'a', ('b', 'c') ]/*
[ 'a' ]
[ ('b', 'c') ]

Fix #2733

Changes the rules for the path operator E1/E2 where E1 selects JNode and E2 evaluates to an atomic value. This now performs context-based mapping, in the normal style for "/", except in the case where E2 is a literal or variable reference, in which case it expands to E1/child::{E2}.

It's really great to be able to write expressions like booklist/book[author='Mike']/price but there are usability traps. Consider this test case:

<test-case name="K2-Steps-40">
      <description> 
         RHS of "/" operator can be any PostfixExpr. 
         LHS of dynamic function call is coerced from JNode to function(*)* 
      </description>
      <created by="Michael Kay" on="2026-04-24"/>
      <dependency type="spec" value="XP40+ XQ40+"/>
      <test>{"A":1, "B":{"C":3, "D":4}}/B/.("C")</test>
      <result>
         <assert-eq>3</assert-eq>
      </result>
   </test-case>

The test is wrong: can you see why? The answer is that it successfully evaluates the final step .("C") to obtain the value 3, but it doesn't return 3 as the final result of the expression, rather it computes {"A":1, "B":{"C":3, "D":4}}/B/3 which returns nothing.

I'm coming to the view that this isn't acceptable. The semantics of G/A where G evaluates to a GNode and A evaluates to an atomic value are wildly different depending on whether G is an XNode or a JNode, and this is going to cause no end of confusion.

A possible solution is to allow the current semantics only in the case where the step is an NCName or a literal. If it's anthing else, for example a variable reference, you have to write G/child::{$i}. If A is any expression other than an NCName or a literal, then G/A works with JNodes the same as it does with XNodes - the "/" operator is essentially treated as "!".

We're still breaking referential transparency; writing 23 has a different effect from using a variable whose value is 23. That's essentially because "/" was never a pure operator in the first place, there have always been surprises in its semantics.

Fix #2708

Fix #2709

(at least in part...)

In most of the parts making up the XPath and XQuery spec (with the exceptions of front and back matter), I have made the document well-formed by (a) adding a wrapper fascicle element where necessary (and declaring this in the DTD), and (b) eliminating external entity and character references that depend on the internal DTD subset.

The &language; entity reference is replaced by the processing instruction <?inject language?>

I have modified the assemble-specs stylesheet to:

• shallow-skip the fascicle element
• expand the <?inject?> processing instruction

Fix #2709

(at least in part...)

In most of the parts making up the XPath and XQuery spec (with the exceptions of front and back matter), I have made the document well-formed by (a) adding a wrapper fascicle element where necessary (and declaring this in the DTD), and (b) eliminating external entity and character references that depend on the internal DTD subset.

The &language; entity reference is replaced by the processing instruction <?inject language?>

I have modified the assemble-specs stylesheet to:

1. shallow-skip the fascicle element
2. expand the <?inject?> processing instruction

See https://github.com/qt4cg/qtspecs/pull/2717#issuecomment-4802675128:

In a replacement string, I suggest the syntax $<group-name>. In a replacement function (which is new in 4.0), I suggest we make the second argument a map of groups rather than a sequence of groups.

Is it not working because I did it wrong, or because GitHub infrastructure is collapsing? Who can tell?

See https://github.blog/changelog/2026-06-18-safer-pull_request_target-defaults-for-github-actions-checkout/