@qt4cg statuses

This page displays recent status updates about the QT4CG project.

The are also captured in an RSS feed.

By year: 2026, 2025, 2024, 2023, 2022, 2021, 2020

QT4 CG meeting 162 draft agenda #agenda-04-28

27 Apr at 10:40:00 GMT

Draft agenda published.

Pull request #2593 created #created-2593

23 Apr at 14:41:20 GMT
2592 Change number-parser option to number-format

Fix #2592

Also changes the null option to be of type item()? rather than item()*. With the current spec, a top-level "null" could expand to multiple items which would violate the declared return type of the parse-json function.

Issue #2592 created #created-2592

23 Apr at 10:39:01 GMT
fn:parse-json: parsing numbers

With 4.0, fn:parse-json has been equipped with a number-parser option. It works fine if you know your data in advance. User feedback indicates that it fails to deliver a convenient solution for arbitrary input. In addition, it requires a configuration which allows you to specify function items as options (which is tricky, for example, for command-line options).

Would we take a big risk by making the interpretation of numbers more flexible? We could adopt the rule for fn:element-to-plan, which says:

If the prescribed type is numeric and the value is castable as xs:numeric, then it is output as an instance of xs:integer, xs:decimal, or xs:double depending on the lexical form of the value, following the same rules as for XPath numeric literals. For example, "-1" becomes an xs:integer, 12.00 becomes an xs:decimal, and 1e-3 becomes an xs:double.

I would see many advantages; among other:

  • Obvious integer input could be handled as such without further conversions.
  • We will have fewer losses in roundtripping scenarios with large numbers and many decimal places.
  • Debugging with the adaptive serialization method would become handier (without changing it, see #2389):
(: current result: 1.0e1 :) 
declare option output:method 'adaptive';
parse-json('10')

With this change, I assume that number-parser option can be avoided in most cases, and I cannot think of big trouble that the introduced backward-incompatibility could cause.

Issue #2591 created #created-2591

22 Apr at 11:35:07 GMT
Grammar: step?lookup is currently invalid

According to the current grammar, I believe that step?lookup is not a valid expression. My reasoning (let’s see if I missed something):

  1. step on its own is not a PrimaryExpr. A name can only occur as a NameTest inside StepExpr/AxisStep.
  2. A lookup attaches only to a PostfixExpr, which starts with a PrimaryExpr.
  3. Inside a RelativePathExpr, consecutive steps must be separated by / or //.

I think we can live with the restriction, but it may be a reason for avoiding wild mixtures of paths and lookups in practice.

Related is the last example in map:build. It uses ./ancestor-or-self::jnode()?name, and I think it needs to be (./ancestor-or-self::jnode())?name.

Issue #2590 created #created-2590

22 Apr at 10:06:35 GMT
Editorial notes (incremental)

Carrying on the tradition of #2408:

  • [ ] FODC0013: Raised when the the options
  • [ ] …

To keep the list short, I will incremental edit my existing comments until the next PR is finalized.

Pull request #2589 created #created-2589

22 Apr at 08:21:00 GMT
2587 Streamability of context value expressions

Defines streamability rules for new 4.0 constructs impacted by the generalisation of context item to context value.

Fix #2587

Issue #2588 created #created-2588

21 Apr at 20:23:05 GMT
Reintroduce xsl:record

In the latest version of PR #2566, the xsl:record instruction has been dropped from XSLT. This needs to be revisited when the dust has settled: does an instruction of this kind actually add value, and if so, what form should it take?

QT4 CG meeting 161 draft minutes #minutes-04-21

21 Apr at 16:10:00 GMT

Draft minutes published.

Issue #2583 closed #closed-2583

21 Apr at 16:03:40 GMT

Fix typo in example of map type declarations

Issue #2582 closed #closed-2582

21 Apr at 16:02:25 GMT

`bin:hex`: return `xs:hexBinary`?

Issue #2408 closed #closed-2408

21 Apr at 16:01:47 GMT

Editorial notes (incremental)

Issue #2586 closed #closed-2586

21 Apr at 16:01:46 GMT

2408 Misc editorial fixes

Issue #2587 created #created-2587

20 Apr at 23:51:42 GMT
Generalization of Context Item to Context Value impacts streamability analysis

I think that many of the streamability rules in the XSLT 3.0 specification rely on the assumption that the context value will be a single item.

Revising the analysis to handle the generalisation is not only a major piece of work which we are ill-resourced to attempt, it may well have the result that many constructs which were streamable in 3.0 are no longer streamable in 4.0.

I'm therefore inclined to push back on this change, or at any rate to find a way to limit its scope.

QT4 CG meeting 161 draft agenda #agenda-04-21

20 Apr at 11:00:00 GMT

Draft agenda published.

Pull request #2586 created #created-2586

20 Apr at 08:26:55 GMT
2408 Misc editorial fixes

Fix #2408

Issue #2585 created #created-2585

20 Apr at 06:02:38 GMT
Limits (editorial)

Rules regarding limits are scattered around the specifications somewhat arbitrarily. I suggest that they be moved to a single place in the Data Model specification, and unified across XSLT, XPath, and XQuery.

Issue #2584 created #created-2584

16 Apr at 16:27:43 GMT
JNodes: legalize absolute path expressions

I think we should have another thought about JNodes and absolute path expressions. A simple XPath expression that starts with a slash should definitely succeed if a map or array is provided as context value, either externally or via declare context value:

declare context value := { 'data': 123 };
/data

Maybe we could also try to simplify the rules in the specification ([4.6.1 Absolute Path Expressions](https://qt4cg.org/2026-01-28/xquery-40/xquery-40.html#id-absolute-path-expressions)):

The expression consisting of / on its own is treated as an abbreviation for the path expression /..

An expression of the form /PP (that is, a path expression with a leading /) is treated as an abbreviation for the expression self::gnode()/(fn:root(.) treat as (document-node()|jnode())/PP. The effect of this expansion is that for every item J in the context value V:

  1. A type error occurs if J is not a GNode [err:XPTY0020].

This seems confusing to me. My assumption is that…

declare context value := { 'data': 123 };
data

…does not raise an error. Why would self:gnode() do so, which is also a single relative XPath step?

Related: #2359

Pull request #2583 created #created-2583

16 Apr at 13:02:55 GMT
Fix typo in example of map type declarations

declare type app:invoice as map("xs:string", element(inv:paid-invoice)); should not use "xs:string" but xs:string

Issue #2582 created #created-2582

15 Apr at 15:56:57 GMT
`bin:hex`: return `xs:hexBinary`?

Can we change the return type of bin:hex from xs:base64Binary to xs:hexBinary? This way, we could get rid of baffling constructs like:

'41' => bin:hex() => xs:hexBinary()

It would be a backward-incompatible change, but one that will hardly be noticed: thanks to the 4.0 coercion rules, xs:hexBinary and xs:base64Binary can now be used interchangeably.

QT4 CG meeting 160 draft minutes #minutes-04-14

14 Apr at 15:50:00 GMT

Draft minutes published.

Issue #2561 closed #closed-2561

14 Apr at 16:03:05 GMT

Definitions: methods and method calls

Issue #2578 closed #closed-2578

14 Apr at 16:03:03 GMT

2561 Explain and define methods and method calls

Issue #2574 closed #closed-2574

14 Apr at 15:40:30 GMT

2550 Shadow attributes in RELAX NG grammar (alt)

Issue #2575 closed #closed-2575

14 Apr at 15:38:04 GMT

xs:error function

Issue #2577 closed #closed-2577

14 Apr at 15:38:02 GMT

2575 Make xs:error available unconditionally

Issue #1584 closed #closed-1584

14 Apr at 15:37:46 GMT

Review the XML Schema and RELAX NG schemas for XSLT 4.0 for compatibility

Issue #2581 created #created-2581

14 Apr at 08:02:28 GMT
XSLT Match patterns for GNodes

The semantics of patterns in XSLT have been changed so that the patterns for XNodes and JNodes are completely distinct. However, this is not reflected in the prose, which still has a single section describing "GNodePatterns" implying that the same pattern can match both. Fixing this is largely editorial, though it may benefit from some refactoring of the grammar.

QT4 CG meeting 160 draft agenda #agenda-04-14

13 Apr at 11:00:00 GMT

Draft agenda published.

Issue #2580 created #created-2580

13 Apr at 11:11:35 GMT
XSLT Match patterns for records

Having dropped extensible record types, we are now left with no easy substitute for the convenient XSLT match pattern

match="~record(first, last, *)"

which would match anything having fields first and last.

I propose we fill the gap with a "map pattern" which might take the form

match="{first, last}"

or

match="{first: ~enum('John', 'Jane')}"

or

match="{r: ~xs:double[. ge 0], i: ~xs:double[. ge 0]}"

What follows the ":" is an optional SequencePattern, defined as a Pattern followed optionally by an OccurrenceIndicator.

Issue #2579 closed #closed-2579

10 Apr at 09:54:20 GMT

Accept narrative errors in generated tests

See 5346 more statuses in yearly archives.