@qt4cg statuses

This is basically a revival of #2300. The current spec says:

All functions defined in this specification are deterministic unless otherwise stated. Exceptions include the following […]:

• Some functions (such as fn:doc and fn:collection) create new nodes by reading external documents. Such functions are guaranteed to be deterministic by default (some such functions have an option "stable":false() that makes them nondeterministic as a user option, and implementations may also provide configuration options to change the default).

A discussed in Meeting 176, we need to decide whether we want to keep this definition alive.

#2831 as well fn:doc and possibly other functions need to be rewritten if we revert the rules to the 3.1 state.

In the fn:serialize rules, xml is defined as the default serialization method. With the focus on JSON data and JNodes, this seems outdated. We should make the behavior more flexible, either…

1. by choosing the serialization method dynamically, depending on the input (first item? each item?), or
2. by extending the xml method to maps and arrays.

Next, Michael noted in https://github.com/qt4cg/qtspecs/issues/2846#issuecomment-5319480097:

fn:serialize says: "If the second argument is omitted, or is supplied in the form of an output:serialization-parameters element, then the values of any serialization parameters that are not explicitly specified is [implementation-defined], and may depend on the context."

(But that's inconsistent with saying that the default value for the second argument of fn:serialize is {}, which does define method="xml" as the default.)

If we keep the first sentence, it should be “specified ~~is~~ are [implementation-defined]”.

Both changes will affect the functions in the File Module.

Both file:append and file:write leave the serialization format implementation-defined if no serialization parameters are supplied. This is explicit in the 4.0 spec, implicit in the 1.0 spec. But test cases have to make assumptions, for example EXPath-file-append2-002 assumes XML serialization (with or without an XML declaration). EXPath-file-append2-001 outputs four atomic values and assumes they will be space-separated, which has no justification in the spec. EXPath-file-appendText2-001 makes multiple calls on file:append() and assumes the values are appended with no newline or separator: again, I don't think there's anything in the spec to justify this assumption.

An implementation that chose JSON serialization would probably fail all the test cases.

Furthermore, even if serialization options are specified, it's unclear whether file:append should add a newline after the appended content. (This is also true, though less important, for file:write). That's because none of the serialization methods (with the possible exception of canonical XML/JSON) says explicitly whether the serialized output is followed by a final newline.

If multiple calls on append() don't add a newline (as suggested by EXPath-file-appendText2-001) this means that any required newline separators must be added manually; but even the effect of file:append(char('\n')) is implementation-defined; appending char('\d')||char('\a') may cause the CR to be escaped as 
.

It's also unclear how you append a simple string to a file without getting any escaping of special characters (except of course by using a different function such as file:append-text()). All the available serialization options do some kind of escaping. Yet surely, appending a string without escaping is the most common use case!

I think my preferred solution would be to say that in the absence of serialization options, we append the result of string-join($value, ' ') to the file. That's certainly going to break some existing applications, but since the current spec is so implementation-defined, it's hard to see how to do better. It merely says that $value is appended to the file in some unspecified way. An implementation that appended string-join($value, ' ') would be entirely conformant to the 1.0 spec, though it wouldn't pass all the test cases.

The CSV rules seem to contradict the pseudo-code. In the pseudo-code, <columns> is emitted whenever exists($colNames). The prose says…

If non-empty column names are available for some columns but not for others, then (a) the empty column element is included within the columns element if and only if there is a subsequent column with a non-empty name, […]

The text was introduced with be078f51 as a resolution for https://github.com/qt4cg/qtspecs/issues/1675.

I think the prose should win. The pseudo-code is broken anyway ($colNames is declared, $colnames is referenced; the rule from above is not implemented at all), perhaps:

let $parsed := parse-csv($value, $options)
let $names  := $parsed?columns
let $last   := foot(index-where($names, fn { . != '' }))
return document {
  <csv xmlns="http://www.w3.org/2005/xpath-functions"> {
    if (exists($last)) {
      <columns>{ subsequence($names, 1, $last) ! <column>{ . }</column> }</columns>
    },
    <rows>{
      for $row in $parsed?rows
      return <row>{
        for member $field at $col in $row
        return <field>{
          if ($names[$col] != '') { attribute column { $names[$col] } },
          $field
        }</field>
      }</row>
    }</rows>
  }</csv>
}

The fn:path entry is internally inconsistent after PR #2706.

At current qtspecs master (211c5d0b13e63a569b79f9764b6803c59a336563), the normative rule for a JNode whose key has a type other than the specifically enumerated string, numeric, QName, and boolean cases requires:

child::{xs:T("S")}

including the enclosing braces. This is stated in function-catalog.xml. An xs:date or xs:dayTimeDuration key falls under this rule.

However, the date-key example later in the same fn:path entry still gives the pre-PR-2706 result (source):

let $in := [ { xs:date('2026-04-18'): 1, xs:date('2026-03-04'): 2 } ]
return path($in/*/*[. = 2])

/1/xs:date("2026-03-04")

Under the current rule, the expected result should instead be:

/1/child::{xs:date("2026-03-04")}

This inconsistency is observable in the generated tests:

• path111 expects /3/1/child::{xs:date("1999-12-31")}.
• path117 expects /3/1/child::{xs:dayTimeDuration("PT6H")}.
• Generated example test fo-test-fn-path-021 reproduces the stale spec example and expects /1/xs:date("2026-03-04").

The direct tests and generated example therefore cannot all pass in one conforming implementation.

Could the result in specifications/xpath-functions-40/src/function-catalog.xml be changed to:

'/1/child::{xs:date("2026-03-04")}'

The static context for (a) xsl:evaluate and (b) static expressions does not include the EXPath bin and file libraries. These should be included if these optional features are supported.

Fix #2801

Fix #2838

Fix #2825

Fix #2836

Adds a dm:location accessor in the data model and a corresponding fn:location function in F+O; a location is a four-part record containing system id, public id, line number, and column number.

Allows maintenance of location information to be requested in fn:doc, fn:parse-xml, etc.

Changes the diagnostics returned by xsd-validator to include a location record.

It seems to me that the function "decode-from-uri" is a misnomer. It probably arose because of a desire for symmetry with "encode-for-uri". But the reason that function wasn't named encode-uri is because the input isn't a URI; the encoding is done as part of the process of producing a URI from a non-URI. The reverse process, however, operates on a URI. "Decode" as an English verb takes the thing being decoded as a direct object, not an indirect object, so the semantically and grammatically correct name is "decode-uri".