@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 minutes #minutes-04-28
Draft minutes published.
Issue #2345 closed #closed-2345
2299 Expand pipeline to allow arrow expression in path expression
Issue #2489 closed #closed-2489
fn:parts-of-dateTime, fn:parse-uri: names & types
Issue #1310 closed #closed-1310
add fn:match-groups() function
Issue #2470 closed #closed-2470
1310 Function fn:matching-segments
Issue #2598 created #created-2598
Add regex() function
Add a regex($pattern, $flags) function to construct a "compiled" regular expression. This gives a clear signal that the same regular expression might be used repeatedly; it avoids relying on caching, which can be unnecessarily expensive and is not predictable across implementations.
Two possible ways this might work:
(a) allow the result of the regex() function to be used as an argument to functions such as matches(), tokenize(), etc, in place of the $pattern and $flags arguments
(b) make the regex() function return a record with methods matches(), tokenize(), replace() etc whose functionality corresponds to the existing functions.
The second approach seems easier to fit into the type system. With the first approach, it's unclear what kind of value the regex() function should return.
Issue #2597 created #created-2597
XSLT syntax scraps recurse too deeply
Some of the syntax scraps in the XSLT spec recurse much too deeply, see for example 6.3.2.1 Predicate Patterns
In the XPath/XQuery specs, the expansion stops when a construct is reached whose name appears at the head of its own scrap. This doesn't work for XSLT patterns because the expansion is in a different spec.
Pull request #2596 created #created-2596
2580 Map patterns
Fix #2580
Pull request #2595 created #created-2595
DM edits on XML Schema data types
Edits here were motivated by several points that caused me confusion tonight:
- 4.1.2 and 4.1.5 had duplicate text, an indication that they belong next to each other.
- In 4.1.2 there were no pointers to the definitions of the datatypes discussed.
- The fifth bullet point in 4.1.2 is not a schema type (which is the topic of the unordered list). The material belongs outside the list.
- The fifth bullet point claims that XDM defines two data types, but it doesn't. And it doesn't mention another data type discussed in predefined data types.
- There is a long discussion of
xs:errorin the XPath specs, but the reader of this section has no clue on wherexs:erroris defined or explained.
Etc. I suspect my draft here still has problems, but I hope it's an improvement.
QT4 CG meeting 162 draft agenda #agenda-04-28
Draft agenda published.
Pull request #2594 created #created-2594
2389 Adaptive Serialization: more freedom
Closes #2389
Pull request #2593 created #created-2593
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
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 ofxs:integer,xs:decimal, orxs:doubledepending on the lexical form of the value, following the same rules as for XPath numeric literals. For example,"-1"becomes anxs:integer,12.00becomes anxs:decimal, and1e-3becomes anxs: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
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):
stepon its own is not aPrimaryExpr. A name can only occur as aNameTestinsideStepExpr/AxisStep.- A lookup attaches only to a
PostfixExpr, which starts with aPrimaryExpr. - 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
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
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
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
Draft minutes published.
Issue #2583 closed #closed-2583
Fix typo in example of map type declarations
Issue #2582 closed #closed-2582
`bin:hex`: return `xs:hexBinary`?
Issue #2408 closed #closed-2408
Editorial notes (incremental)
Issue #2586 closed #closed-2586
2408 Misc editorial fixes
Issue #2587 created #created-2587
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
Draft agenda published.
Pull request #2586 created #created-2586
2408 Misc editorial fixes
Fix #2408
Issue #2585 created #created-2585
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
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 expressionself::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:
- 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
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
`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
Draft minutes published.
See 5356 more statuses in yearly archives.