@qt4cg statuses

Fix #2774

This PR reverts the effect of PR 2747, which introduced the ability to write the expression A/B?C, with the lookup ?C being part of the step (B?C).

As discussed in the issue, the problem is the interaction with the rules on sorting nodes into document order and deduplication. The expression "feels like" it should evaluate (A/B) ? C - typically searching a JTree to obtain a JNode that wraps a map, and then extracting the entry C from that map; but that's not the actual semantics, because assuming that ?C doesn't select JNodes) it disrupts the deduplication and sorting that (A/B) would otherwise undertake.

Following acceptance of PR #2759, if declare item type is used to define a name for a record type, then the record type acquires a constructor function. The spec for "declare item type" at §5.19 refers to §4.21.5 constructor functions, but that section does not define any semantics for a constructor function for instances of a record type.

Now that item types have constructor functions, it is increasingly hard to justify having both named item types and named record types as separate features. I think we should merge them. Specifically:

• allow all named item types to be recursive
• allow all record declarations to define default values for fields (these can be used when coercing a map to a record type). But I would suggest that the default value must be a constant
• allow all record declarations to define methods.

Also: do we get a constructor function if the field names are not NCNames?

The current specs take the position that fragment identifiers are implementation defined:

The effect of a fragment identifier in the supplied URI is implementation-defined. One possible interpretation is to treat the fragment identifier as an ID attribute value, and to return a document node having the element with the selected ID value as its only child.

I think this is an interoperability problem. Ignoring, or failing to correctly interpret, a fragment identifier can have a profound impact on the document processed. If the processor silently ignores fragment identifiers, I may get wildly incorrect results. In a workflow involving many documents or large documents, or both, this could be difficult to catch.

I think it would be better to say:

1. The fragment identifier schemes supported by a processor are implementation-defined. (So, technically, implementations must enumerate the schemes they support.)
2. Processors must report an error if they encounter a fragment identifier that uses a scheme that they do not recognize or cannot cannot be processed (because of implementation limits, or syntactic errors in the scheme, etc.)
3. Implementations should support the xmlns and element schemes for XML documents and RFC 5147 for text resources. Obviously, they may support other schemes as well.

I propose that the current set of tunnel parameters should be available dynamically via a new XSLT-only function tunnel-parameters(), returning a map indexed by QName.

The main benefits are:

(a) it becomes possible for an instruction to test whether a tunnel parameter exists (declaring it with required="no" and a default value is a messy and unsafe way of achieving this)

(b) it becomes possible to write template match patterns that use tunnel parameters as part of the template despatch mechanism (see issue #108)

This proposal was influenced by the discussion on #2737, though it eventually emerged from that discussion that the proposer had something rather different in mind

Closes #2783

A simple one:

XPath can format numbers and dates, but it cannot pad a string to a fixed width, although it would often be helpful when creating textual output (reports, log lines, etc.). That’s something most other languages provide.

Users must write it themselves, and the usual workarounds are easy to get wrong. substring($s || ' ', 1, 5) only works if the literal is long enough, and it truncates. $s || string-join(replicate(' ', 5 - string-length($s))) needs two functions and does not feel very intuitive.

The signature, as I would draft it:

fn:pad-string(
  $value    as item()?,
  $length   as xs:integer,
  $options  as map(*)? := {}
) as xs:string

The options could be fill (default " ") and side (end by default, start, both). Examples:

pad-string('abc', 10)                                  (: "abc       " :)
pad-string(42, 6, { 'fill': '0', 'side': 'start' })    (: "000042" :)
pad-string('Chapter 1', 20, { 'fill': '.' })           (: "Chapter 1..........." :)

I tagged this with »Propose Merge without Discussion« as I believe it’s safe to merge. Feedback is always welcome, though.

Many XQFO examples need to be fixed to be compliant with the latest changes in the spec.

Part 1: #2779 Part 2: #2782

I have some comments on 17.5 Functions on CSV Data

The paragraph starting:

The other two functions recognize column names.

There are 3 other functions not 2.

17.5.4 fn:csv-to-arrays In the examples, the results are sometimes shown as sequence of arrays enclosed in () and sometimes not. I know it's not that important, but is it a deliberate decision?

17.5.6 Record fn:parsed-csv-structure-record columns description says:

The sequence of strings will potentially be truncated if the number-of-columns option is specified, and it will potentially be reordered if the filter-columns option is specified.

I assume this is left over from a previous version and should talk about select-columns?

17.5.4 fn:csv-to-arrays and 17.5.7 fn:parse-csv Rules section says:

The input supplied in $value is CSV data, as defined in [RFC 4180].

Should this refer to the extended grammer defined in 17.5, or just not have this sentence at all. Section 17.5.10 doesn't have it.

17.5.7 fn:parse-csv trim-whitespace section: If you have {'header':true(),'trim-whitespace':false()} the 'header' fields are trimmed but not the data fields. The description of trim-whitespace needs to say something about this case.

trim-rows section: It might be better if the false part started 'No padding or trimming of fields in the rows takes place' so that it is explicit this is about field padding/trimming.

17.5.11 Illustrative examples of processing CSV data Example: Converting a CSV into an HTML-style table using fn:parse-csv I have to say that it doesn't look like anyone has tested this. Some comments are:

1. For the $crlf variable could you make the value XSLT/XQuery agnostic by just having the part after ':='?
2. No data is output because the default option for header, false() applies to fn:parse-csv and fn:csv-to-xml.
3. In the XSLT versions some <xsl:template> elements have a closing tag of </xsl:function>.
4. In the first example the code doesn't reflect the record structure.
5. In the first example why is the namespace prefix eg declared and excluded when it isn't used.
6. In the second XQuery example it would help if the references to the CSV XML elements used the correct namespace.