@qt4cg statuses

Fix #2357

We use element(*) and element() interchangeably in function signatures. I propose we standardise on the simpler form, element().

Ditto attribute().

A user experimenting with xsl:for-each-group/@split-when with my 4->3 source-code transformer, inferred that the variable $group was available within the sequence constructor of the grouping instruction.

(Unfortunately due to an error in my transformer code $group was within scope in the sequence constructor, though with the wrong value ;-) - this has since been corrected.)

A close and detailed reading of the spec shows that $group and $next are implied as only in scope for the evaluation of the @split-when expression. Might I suggest that there is a small note emphasising this is the case? Similar clarification may be worthwhile for @merge-when too.

The spec says

If no effective encoding could be chosen, an error is raised.

It's not clear what error is raised.

Under Error conditions, it says

[[bin:invalid-encoding] is raised if $encoding is invalid for the given input.

Does this mean that the function must ensure that the input can be successfully decoded using the returned encoding? This seems wasteful, since decode-string() is going to repeat this test. If it doesn't mean this, what does it mean?

It is trivial to append items to a sequence, but it is a bit counterintuitive to do so the functional way, for example within chains:

(1, 3, 5)
=> fn { ., 7, 9 }()
=> string-join(',')

I propose adding a simple fn:append function, as counterpart of array:append:

(1, 3, 5)
=> append((7, 9))
=> string-join(',')

It is easier to prepend items: we already have fn:insert-before (and array:insert-before).

there's also some kind of markup problem that means the links within the grammar don't always work properly.

Originally posted by @michaelhkay in https://github.com/qt4cg/qtspecs/issues/2345#issuecomment-3661848071

The problem is that some local links are incorrect (don't work), and some items don't have links.

For example, in 4.1 Namespace Declarations, in the line "declare" "default" "element" "namespace" URILiteral,

The html source code for "URILiteral" is:

<a href="#doc-xpath40-DefaultElementNamespaceDecl-URILiteral doc-xpath40-NamespaceDecl-URILiteral">URILiteral</a>

(note a space in the fragment identifier in href)

The code for the first occurrence of URILiteral at the left side is:

<a id="doc-xpath40-DefaultElementNamespaceDecl-URILiteral"></a>
<code><a href="#prod-xpath40-URILiteral">URILiteral</a></code>

(seems correct)

And the code for the second occurrence of URILiteral at the left side is:

<a id="doc-xpath40-NamespaceDecl-URILiteral"></a>
<code>URILiteral</code>

(one anchor is missing, is this intentional?)

The XML source is:

         <scrap role="xpath">
            <prodrecap ref="DefaultElementNamespaceDecl"/>
            <prodrecap ref="NamespaceDecl"/>
         </scrap>

I am trying to understand the exact implications of the trusted execution mode that we have recently introduced. The spec says:

2.3 External Resources and Security

[Definition: The static context includes a boolean property called trusted that determines whether external resources are available.] This may take the following values:

• false: No external resources are available other than resources explicitly made available by the caller through some trusted implementation-defined mechanism.

In the interests of security, the default for these options is false.

How will the rules be interpreted by Saxon? For example,

1. What is meant by »external resources«? Does it refer to remote resources (https://abc.de/fgh.xml) or also to local files?
2. How would the behavior change if the default is changed to true?
3. What could be done to allow or disallow access to local files?

As our current specifications are still in the draft stage, we cannot guarantee that any added or changed features will be part of the final specification. However, as 4.0 features are increasingly used in production code, we should try to revert shaky candidates sooner rather than later.

We can collect possible candidates in this issue:

1. fn:sequence-join has just been renamed to fn:insert-separator (#2329)
2. Do we need syntactic sugar for filtering maps and arrays? #2312
3. We have recently dropped map:pairs and map:of-pairs. Do we still need array:members and array:of-members? If yes, should we define a record type for record(value)?

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.