@qt4cg statuses

As we provide the option parse-xml: strip-space=conditional I think we should make it work consistently with the same option on fn:doc and fn:document - it should strip whitespace according to the XSLT strip-space/preserve-space declarations.

The default should remain "none" to preserve backwards compatibility.

The spec for load-xquery-module says (in a Note!)

If a function declaration F in the loaded module declares (say) four parameters of which one is optional, its arity range will be from 3 to 4, so the result will include two function items corresponding to F#3 and F#4. In the lower-arity function item, F#3, the fourth parameter will take its default value. If the expression that initializes the default value is context sensitive, the static and dynamic context for its evaluation are the static and dynamic contexts of the [fn:load-xquery-module] function call itself.

This is inconsistent with the way the evaluation context for function parameter defaults now works. The context should be the same as for initializers of global variables, for example a default of "." picks up the context item/value defined in the options to load-xquery-module.

If the default refers to fn:current() then I guess this should be bound to the context item for the evaluation of load-xquery-module.

I deliberately ignored Sequence JNodes and the ·jposition· property. I will look at it once #2878 is done.

Simple typos found with the aid of a spelling/grammar checker.

Similar to https://github.com/qt4cg/qtspecs/issues/2872

I'd like to propose that #supports-xinclude system property be renamed to #supports-xinclude-option as an XML processor may include generic support for XInclude but not necessarily support for the xinclude option when using fn:doc and fn:parse-xml. Alternatively, the scope of the #supports-xinclude property might be reduced to generic support for XInclude and an additional #supports-xinclude-option be added for the broader scope.

The scope of #supports-xinclude is currently described as:

Returns true if the processor supports the option "xinclude":true() in calls to fn:doc and fn:parse-xml; otherwise false.

The ability to control whether xi:include elements are processed when parsing an XML document using fn:doc or fn:parse-xml, independently of generic XInclude settings, is managed via an $options parameter (newly added to both functions) and the general rules for Options say that:

All entries in the options map are optional

So an implementation that already provides generic support for XIncludes, is under no obligation to provide the finer-grained control offered via the $options map.

IMHO, it would be ideal if it were possible to use fn:system-properties() to check support for both features:

• #supports-xinclude
• #supports-xinclude-option

However, if that's not a popular suggestion, I think that adding the -option suffix to the current property name would make it more accurate and less confusing.

Fix #2073

Supersedes #2160

This proposal solves the problem of representing JTrees containing sequences of more than one item by introducing an extra JNode for such sequences, called a sequence JNode. The children of a sequence JNode represent the items in the sequence, and their jkey property represents the position of the item in the sequence. This eliminates the need for the jposition property. Navigating trees containing sequence JNodes is awkward because the representation of singleton sequences and non-singleton sequences is not uniform; but such trees never arise in JSON structures and we don't have to optimize their usability. The revised design simplifies mainstream use cases involving JSON by eliminating the jposition property.

Closes #2827

• [ ] Many (perhaps most) fields of fn:schema-type-record say in the prose that the value can be "absent", but the type does not allow an empty sequence.

Closes #2874

I wrote a script to check the syntax of our formal equivalencies, and I noted that many were buggy. I took a closer at what they do and encountered additional bugs. A PR will follow for this issue to fix them.

I thought I’d give the pending JNode update issue another attempt (@joewiz’s #77 is the oldest one that’s still unresolved). This one tries to…

• define a single XPath update function;
• work for both JNodes and XNodes; and
• allow recursive updates, to for example rename all keys a as b.

The signature:

fn:update(
  $input        as gnode(),
  $select       as fn($node as gnode()) as gnode()*,
  $replacement  as item()* := ()
) as item()*

• $select is applied once to $input and returns the nodes to replace. They must belong to $input.
• $replacement is what a selected node becomes. If it is a function item, it is called with the node.
• Replacements are applied bottom-up, so a node reaches $replacement with its descendants already updated.
• A map or array supplied where gnode() is expected becomes a root JNode.
• A root node in substitution position contributes its children, exactly as a document node does in content position.
• Inside an array, the key of a substituted entry is ignored, since positions are renumbered.

The replacement, or the result of the replacement function:

Result | Description --- | --- () | delete the node (default) one atomic item | replace the node’s value, keeping its key or name one node, map or array | replace the node, key or name included several items | replace and insert, each item read as above

An atomic item replaces the value, everything else replaces the node. To assign a map, an array or a sequence as a value, name the key: { jkey($n): [] }.

Examples

Input

let $store := {
  'store': {
    'books': [
      { 'title': 'XQuery', 'price': 39.95 },
      { 'title': 'JSON',   'price': 24.50, 'draft': true() }
    ],
    'open': true()
  }
}

Delete draft nodes

update($store, fn { .//draft })

Increase a value

update($store, fn { .//price }, fn { . * 2 })

Insert a sibling entry

update($store, fn { .//price }, fn { ., { 'currency': 'EUR' } })

Rename books recursively

Nested occurrences are covered: the inner nodes are replaced first, so jvalue($n) already carries the renamed subtree.

update($store, fn($n) { $n//books }, fn($n) { { 'items': jvalue($n) } })

Add a book

update(
  $store,
  fn($n) { $n//books },
  fn($n) { { 'books': array:append(jvalue($n), { 'title': 'Update', 'price': 9.95 }) } }
)

Single-pass update

update(
  $store,
  fn($n) { $n//(price | books | draft) },
  fn($n) {
    if ($n/self::price)      then ($n * 2, { 'currency': 'EUR' })
    else if ($n/self::books) then { 'items': jvalue($n) }
    else ()
  }
)

(: result :)
{ "store": {
  "items": [
    { "title": "XQuery", "price": 79.9, "currency": "EUR" },
    { "title": "JSON",   "price": 49,   "currency": "EUR" }
  ],
  "open": true
} }

XML update

let $store :=
  <store open="true">
    <books>
      <book><title>XQuery</title><price cur="EUR">39.95</price></book>
      <book draft="true"><title>JSON</title><price cur="EUR">24.50</price></book>
    </books>
  </store>
return update(
  $store,
  fn($n) { $n//(price | books | @draft) },
  fn($n) {
    if ($n/self::price) then ($n * 2, <currency>EUR</currency>)
    else if ($n/self::books) then <items>{ $n/@*, $n/node() }</items>
    else ()
  }
)

(: result :)
<store open="true">
  <items>
    <book>
      <title>XQuery</title>
      <price cur="EUR">79.9</price>
      <currency>EUR</currency>
    </book>
    <book>
      <title>JSON</title>
      <price cur="EUR">49</price>
      <currency>EUR</currency>
    </book>
  </items>
</store>

Feedback is welcome…

I'm working on implementing fn:system-properties() per PR2552 and am wondering whether the #supports-dtd property should be renamed #supports-dtd-validation. The description for this property is:

Returns true if the processor fully supports validation, entity expansion, and attribute typing (recognition of ID and IDREF attributes) based on DTD processing during XML parsing. Returns false if there are restrictions, even if some of these capabilities are available.

XML processor profiles states that:

Conformance to [the 2.3] profile, or to the 2.4 The full XML processor profile defined below, neither requires nor excludes validation. They leave it open to specifications which cite them to forbid, allow or require validation.

A non-validating processor (see 5.1 Validating and Non-Validating Processors in [Extensible Markup Language (XML) 1.0 (Fifth Edition)]) conformant to [the 2.3] profile gives the complete infoset of a well-formed XML document. In the absence of well-formedness and validity errors, a validating processor using [the 2.3] profile gives the complete infoset of a valid XML document.

The XML 1.0 spec also makes a distinction between validating processors and non-validating processors.

It seems to me that there are at least 3 relevant categories of processor:

1. a non-validating processor that doesn't fully implement entity expansion and attribute typing.
2. a non-validating processor that fully supports the use of a DTD to build an XML instance that satisfies all the constraints for constructing a document from an XML Infoset, including entity expansion and attribute typing; and
3. a processor that additionally supports validation per the DTD.

The description of the #supports-dtd property includes validation, so it will only return true for processors in category 3 but the processors in category 2 also support the use of a DTD to a significant extent, so, based on the name alone, it would be reasonable to expect that a property named #supports-dtd would return true for them too; the QT4 test suite even already includes a dependency option for them (infoset-dtd).

While the CG may only wish to include a property for the more fully featured processors in category 3, I think that renaming the property to #supports-dtd-validation would more accurately represent its scope and leave less room for confusion.

As an initial step to dealing with issue #2813, this PR reorganizes the contents of sections 25 and 26 of the XSLT specification. Section 25 now deals solely with validation, section 26 deals with delivery of primary and secondary result trees, and in the case of the xsl:result-document section, it splits the very monolithic and poorly structured existing text into subsections each dealing with one topic.

This PR does not change any existing text, it merely reorganizes it.The next stage will be some editorial work to improve the text, but in order to get meaningful diff markup, I plan to do that in a separate PR. For this PR, because there is (if I've got it right) no technical change, I propose accepting it without review,

Fix #2837

Fix #2820

Issue 2820 reported a syntax ambiguity resulting from the addition of occurrence indicators to cast expressions. This PR solves the issue by dropping the occurrence indicators; casting of a sequence to a sequence type is now an internal operation performed when casting an array, map, or record, but is not exposed in user-visible syntax.

Closes #2867