@qt4cg statuses

Fix #2567

Needs finalizing when #2787 is agreed.

Fix #2351 Fix #2393

Changes the array:members() and array:of-members() functions to use JNodes to represent array members rather than using value records.

Generalizes the jtree() function so it can wrap any value as a JNode, not only a map or array -- useful when constructing the input to array:of-members.

Makes corresponding changes to XSLT examples. This is generally a simplification because xsl:array and xsl:array-members already use JNodes for this purpose.

Satisfies action QT4CG-167-05

In the context of XProc, I learned that an xsl:result-document element without any href attribute writes to the principal result port, not the secondary output port. Can the XSLT specification clarify that the body of xsl:result-document without @href becomes a principal result instead of a secondary result?

The definition at https://qt4cg.org/specifications/xslt-40/Overview.html#dt-secondary-result doesn’t address this point.

[Definition: Zero or more secondary results: each secondary result can be any sequence of items (as defined in [XDM 4.0]).] A secondary result is the value returned by evaluating the body of an xsl:result-document instruction.

Also, in https://qt4cg.org/specifications/xslt-40/Overview.html#result-trees the paragraph that begins with “The href attribute is optional.” might be a good place to describe the behavior (not just the URI) if you omit @href.

If you think these clarifications belong in the XProc specification instead of the XSLT specification, that is fine with me. I actually looked in the XProc specification first. Maybe the part of https://spec.xproc.org/3.1/steps/#c.xslt that says “the principal result(s) will appear on output port result while secondary result(s) will appear on output port secondary” can say how you know which results are considered principal vs. secondary.

Closes #2811

We decided that fn:decode-from-uri should turn a plus character into a space, so that a+b.xml is decoded as a b.xml.

That rule actually comes from HTML form data (as I was noted), not from URIs, so the function does not really do what its name promises. It does not match its own counterpart fn:encode-for-uri either, which writes + as %2B. In addition, it seems to break fn:parse-uri, which reuses the same decoding for path segments.

We could add an option to control the behavior for +, but it may be over the top.

Summary

The generated F&O examples for fn:parse-uri appear to conflict with the current record semantics introduced by qt4cg/qtspecs#2566 and with the dedicated fn:parse-uri tests in qt4tests.

Details

The dedicated test set:

https://github.com/qt4cg/qt4tests/blob/master/fn/parse-uri.xml

expects the result map to contain the complete set of declared fields. Components that are not present in the input URI are represented by fields whose values are empty sequences.

This was updated in:

https://github.com/qt4cg/qt4tests/commit/7df0076630e11b49f94e4a9d7d85ed955a44cf1e

That appears consistent with the record semantics described by https://github.com/qt4cg/qtspecs/pull/2566.

In particular, a record contains all of its declared fields, although the value of a field may be an empty sequence.

However, the generated F&O example tests here still expect sparse maps for fo-test-fn-parse-uri-001 through fo-test-fn-parse-uri-027: fields corresponding to absent URI components are omitted from the expected map.

Thus, an implementation returning the complete record-shaped map passes the dedicated fn:parse-uri tests but fails the generated F&O examples. Returning sparse maps has the opposite result. Satisfying both seems impossible.

Both sets of tests appear to target the current XPath/F&O 4.0 specifications.

Expected resolution

Could the fn:parse-uri examples in the F&O specification, or the mechanism that generates their assertions, be updated so that absent URI components are represented consistently with the record semantics from #2566?

The generated qt4tests/app/fo-spec-examples.xml file says it should not be edited directly, so I believe the correction belongs in qtspecs.

If the debug option is enabled, fn:deep-equal should be treated as nondeterministic function. Otherwise, debugging may be skipped.

• The function fn:doc has the option strip-space with the enum values all, none, and conditional.
• The functions fn:parse-xml and fn:parse-xml-fragment have an option with the same name, but a Boolean value.

Proposal:

• unify on enum("all", "none", "conditional") for all four (including fn:doc-available), defining conditional as none for fn:parse-xml(-fragment).
• If we prefer to keep different types, we should add an explanatory note.

Copied from https://github.com/qt4cg/qtspecs/pull/2712#pullrequestreview-4615985800, something we should at least discuss:

The rules of this PR combined with #2734 have the potential to break ordinary XML paths. A parser may rewrite <xml/>/data() to:

<xml/>/(
  if (. instance of node()) then name() else (
    if (. instance of node()) then (
      let $A as ... := fn(){ data() }() return ...
    ) else (
      let $A as ... := fn(){ data() }() return ...
  )
)

As XPTY0004 can be raised statically, fn(){ data() } may result in a static error, and the full query will be rejected although the paths in question would never be executed.

Maybe we should stress that the presented equivalent code is to be understood as equivalent code that cannot be simply pasted by the parser (?). Or we simply drop the equivalent representation and liimt ourselves to formal rules.

Adopted from https://github.com/qt4cg/qtspecs/pull/2719#issuecomment-4904849541:

I think that allowing spaces, tabs, and newlines as literal characters representing themselves is hopelessly error prone, partly because it's not distinguishable to the human reader, and partly because serialization parameter values can be written as XML attributes, which are subject to attribute value normalization. Backslashes are less error prone (though when the spec says that the value must match \\t, the spec gets confusing). I would suggest making it simpler: indent-unit="SSS" for three spaces, or indent-unit="T" for one tab, and use newline="NL | CR | CRLF"

The attempt… which closes #2802 if accepted. Much of the prose is derived from the original version of the spec.

I revived the strict type error for fn:deep-equal($fn1, $fn). I believe we shouldn’t re-introduce implementation-dependent behavior; I don’t think it would have enough added value.

…and other editorial fixes.

Closes #2780

Closes #2773

I think we should reconsider whether it was a good idea to give functions public identities:

• It’s a feature you can see but are told not to trust: The result of fn:function-identity will depend completely on the implementation.
• If we keep it, all built-in functions that create functions will need to become non-deterministic (see #1920), with the drawback that the effects of nondeterminism again depend on the implementation. Among others, this includes fn:parse-json, fn:apply, or fn:op.
• It could simplify the prose of fn:jtree. The current notes revolve alot around the function identity, but it is not clear why: Since the identity is unpredictable, the behavior of fn:jtree will be too.

fn:deep-equal could be equipped with an option to ignore functions other than maps and arrays.

I may need a memory refresher: Are there are language features that would suffer from the reversal?

The result of matching-segments() includes for each match, a map containing information about the captured groups for that match.

The result of regex-groups() provides a map containing information about the current match being processed by xsl:analyze-string.

I propose to align the definition of these two maps, which are currently needlessly different.

Closes #2799