@qt4cg statuses

The attribute xsl:mode/@typed needs to be extended (or at least clarified) to explain how non-nodes and JNodes are handled.

Fix #2330 Fix #2334 Fix #2336

Currently work-in-progress

This PR changes the syntax and semantics of JNode types, tests, and patterns, bringing them closer into line with each other and with the corresponding constructs for XNodes. It also fixes problems of grammar ambiguity.

JNode types are revised to take the form jnode(selector-value, content-type), mirroring the syntax of element and attribute types, and bringing them into line with JNode patterns. This also enables JNode patterns to be integrated with XNode patterns, using common syntax and semantics.

Subtyping rules for JNode types are added.

When types are used for selection in a JTree, the type must now be a JNode type, not the content type. For example, in place of $array/map(*), you need to write $array/jnode(*, map(*)). While more verbose, this syntax is more consistent with selection in XTrees, and is more powerful. (It also offers potential extensibility to eliminate the get(X) construct).

In XSLT patterns, union/except/intersect now apply only to node patterns (reverting a 4.0 enhancement which caused parsing difficulties). The semantics of except and intersect have also reverted to the 3.0 semantics.

XSLT type patterns are now uniformly written ~ItemType, rather than using the bare item type in some cases (such as record types), and the more verbose syntax type(ItemType) in other cases.

Is it possible to make the JNodeType form similar to ElementTest and JNodePattern (in XSLT)?

ElementTest has the form:

ElementTest 	::= 	"element" "(" (NameTestUnion ("," TypeName "?"?)?)? ")"
NameTestUnion 	::= 	(NameTest ++ "|")

And JNodePattern currently has the form:

JNodePattern ::="jnode" "(" JNodePatternSelector "," JNodePatternContent ")" Predicate*
JNodePatternSelector 	::= 	"*" | NCName | Constant

But JNodeType has the form:

JNodeType 	::= 	"jnode" "(" SequenceType? ")"

I think, this introduces an inconsistency.

The expected forms are:

JNodePattern ::= JNodeType Predicate*
JNodeType 	::= 	"jnode" "(" (JNodePatternSelector ("," JNodePatternContent )? )? ")"
JNodePatternContent 	::= 	"*" | SequenceType

Probably, JNodePatternContent is not needed, since JNodePattern jnode() should be equal to jnode(*,*) in the current spec. Then, SequenceType should be used instead of JNodePatternContent in JNodeType:

JNodePattern ::= JNodeType Predicate*
JNodeType 	::= 	"jnode" "(" (JNodePatternSelector ("," SequenceType )? )? ")"

This form is not only more consistent, but also it provides a more concise way to select GNodes by matching both their selector property and their jnode() type:

• $g / jnode( foo ) will be equivalent to $g / foo [ self::jnode() ]
• $g / jnode( foo, xs:integer ) will be equivalent to $g / foo [ self::jnode() ][ jnode-content() instance of xs:integer ]
• $g / jnode( *, xs:integer ) will be equivalent to $g / jnode() [ jnode-content() instance of xs:integer ]

Probably, JNodePatternSelector can be changed to JNodeSelectorUnion to support unions like NameTestUnion in ElementTest:

JNodeType 	::= 	"jnode" "(" (JNodeSelectorUnion ("," SequenceType )? )? ")"
JNodeSelectorUnion ::= JNodeSelector ++ "|"
JNodeSelector ::= "*" | NCName | Constant

Side note: It appears that despite of the name ElementTest, an expression of the ElementTest production represents a type, the same as JNodeType.

This topic was also discussed a bit in #2099 (comment), and the analogy was mentioned in #2150: "An analogy with element(N, T) might suggest match="jnode(K, V)" where K constrains the selector property of the JNode, and V constrains its content property".

We seem to have a problem with parenthesized subexpressions / sub patterns within a pattern.

We have an extra-grammatical rule:

The content of any ParenthesizedPattern within an XNodePattern that contains a / or // operator (other than within a predicate) must itself parse as an XNodePattern.

This appears to rule out parenthesized sub-expressions that contain both a "/" and a "|" operator, for example a/(b/@x | c/@x)

The rule is obviously pretty bizarre, and the reason we have it is so that any XNodePattern is a syntactically valid XPath expression, which ensures that we can define the semantics of the pattern in terms of the semantics of XPath expressions.

Ideally we would have different productions for a parenthesised pattern at the top level, and a parenthesised expression within an XNodePattern, but we know that leads to ambiguities (or at any rate, a need for unbounded lookahead). But the current rule isn't an adequate solution.

In XQuery and XPath Data Model 4.0, the section 3.2.1 empty-sequence Constructor defines dm:empty-sequence() as:

• dm:empty-sequence() as item()*
  The dm:empty-sequence constructor returns a sequence containing no items.

Why is the return type specified as item()* and not empty-sequence()? Is this an oversight or intentional?

Note that 4.2 Type System mentions a sequence of exactly zero items (emphasis mine):

• [Definition: A sequence type constrains the set of permitted sequences, by defining the permitted item types and the permitted number of items in the sequence (exactly zero, exactly one, zero-or-more, one-or-more, zero-or-one).]

Addresses issues raised in issue #2195

Fix #2330

In the XSLT pattern syntax, an ArgumentP is constrained to be either a variable reference or a Literal.

Elsewhere in the pattern syntax, we allow a Constant rather than a Literal. A Constant additionally allows (a) a negative number, and (b) true() and false().

ArgumentP is used where the pattern starts with a function call, which must be one of doc(), id(), element-with-id(), key(), or root(). Of these only key() can take a non-string argument, and it's unlikely that booleans or negative numbers will be useful very often, but it's worth making the change in the interests of consistency.

Reverts the function to its original name.

The name sequence-join seems to be based on a false analogy with string-join (which joins multiple strings with an optional separator) and array-join (which joins multiple arrays with an optional separator). The sequence-join function is quite different, it does not join multiple sequences. The name intersperse far better describes what the function actually does.

Fix #2326

I had some trouble finding the sequence-join function because I couldn't remember what we ended up callling it.

The name seems very poorly chosen for a function that doesn't join sequences. It was chosen, I'm sure, by analogy with string-join(), but whereas string-join does actually join multiple strings, and array-join joins multiple arrays, sequence-join does not join multiple sequences. The old name intersperse seems better.

That's assuming we need the function at all -- it seems of fairly modest value.

During review of the CDATA proposal today it was suggested that we should offer some rules or at least guidance on the interaction of xsl:text/@cdata with other features:

• Sequence normalization (esp merging of adjacent text nodes)
• cdata-section-elements
• Unicode normalisation
• character maps