@qt4cg statuses

Fix #2816

Where the new indent-unit and newline serialization parameters are specified as XML attributes, specifically in XSLT xsl:output or xsl:result-document or in a serialization parameter file, we should warn people of the dangers posed by XML attribute value normalization, and advise the use of XML character references such as newline="
" or the escape form newline="\r\n".

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.