@qt4cg statuses

@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 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

Adopted from https://github.com/qt4cg/qtspecs/issues/2195#issuecomment-3426412436, and raised because of new user feedback:

Now that we have dropped map:pairs, the map filter expression is the only remaining that represents map entries as record(key, value).

For the sake of simplicity and usability, we could question if the alternative writings for both filtering maps and arrays are not sufficient:

let $map := { 0: 1, 1: 2, 2: 4, 3: 8 }
let $filter := fn($k, $v) { $k = $v - 1 }
return (
  (: existing ways of filtering map entries :)
  map:filter($map, $filter),
  { for key $k value $v in $map where $filter($k, $v) return { $k: $v } },
  (: redundant? :)
  $map?[$filter(?key, ?value)]
)

let $array := [ (), 1, (2, 3), (4, 5, 6) ]
let $filter := fn($m) { count($m) > 1 }
return (
  (: existing ways of filtering array members :)
  array:filter($array, $filter),
  array:join(for member $m in $array where $filter($m) return [ $m ]),
  (: redundant? :)
  $array?[$filter(.)]
)

The rules for default priorities for type patterns and predicate patterns do not follow the convention that defaulted priorities are always less than 1. The default of 1 in these cases should be reduced to 0.5.

4.7.2 Relative Path Expressions, states that:

Each non-initial occurrence of // in a path expression is expanded as described in 4.7.7 Abbreviated Syntax, leaving a sequence of steps separated by /.

but as far as I can see, 4.7.7 Abbreviated Syntax doesn't currently have any specific mention of what the expansion actually is.

XPath 3.1, 3.3.5 Abbreviated Syntax does have a third list item describing the /descendant-or-self::node()/ expansion, but it seems to have disappeared in at least the current version of 4.

Fix #2299

Allow the form A => B() ! C and make it equivalent to ( A => B() ) ! C. Also, allow all operators from PostfixExpr in the same manner.

Fix #2305

The result was buggy, causing errors in examples, and the highlighting wasn’t actually having any effect because the CSS had been lost.

Need $member?value not $member

I'm seeing an example in the XSLT spec, section §17.3 that is incorrectly rendered:

<xsl:analyze-string select="'aLongPieceOfString'">regex="(?<=[a-z])(?=([A-Z]))">

Note the '>' before 'regex'.

Looking at the HTML, I see

<pre class="spectrum"><span class="es">&lt;</span><span class="enxsl">xsl:analyze-string</span><span class="z"> </span><span class="atn">select</span><span class="atneq">=</span><span class="z">"</span><span class="op">'</span><span class="literal">aLongPieceOfString</span><span class="op">'</span><span class="z">"</span><span class="scx">&gt;</span><span class="txt">regex="(?</span><span class="es">&lt;</span><span class="en">=[a-z])(?=([A-Z]))"</span><span class="scx">&gt;</span><span class="txt">

Now, in the XSLT 3.0 spec, examples like this were syntax highlighted, and it looks to me as if we're still putting the example through the syntax highlighter, but we've dropped the CSS that actually produces the highlighted rendition. And I suspect that in this case we're seeing a bug in the syntax highlighter.

If I recall correctly, the name "spectrum" refers to a syntax highlighting tool written by Phil Fearon, but I can't find any references to it on the web.

Since we're not taking advantage of the syntax highlighting, and since no-one has complained about its absence, and since it appears to have a bug, perhaps the best thing is to drop it from the processing pipeline.

Transferred from issue #2195 as it seems to be rather complex.

The EXPath binary spec is being published at location https://qt4cg.org/specifications/expath-binary-40/Overview.html but internal links generated from function markup elements are pointing to https://qt4cg.org/specifications/EXPath/binary-40/Overview.html

The incorrect URI is generated because of the variable at xmlspec-2016 line 723; the correct URI is also there, commented out.

But simply changing this variable doesn't work (which is presumably why it's commented out). This is because the incorrect URI also appears in other places. It's in the doc.public entity definition in the heading of the document itself, it's in /etc/BIN40, and it's in database.xml. I haven't managed to work out the process by which these references are generated.

The same factors apply equally to the EXPath file specification.

Allow xsl:text and xsl:value-of to request serialization of the content as a CDATA section.