Action 335: Clarifications for fn:count argument

[mbeckerle]

fn:count and related functions are described as taking node sequences. Arrays/Optional elements are not mentioned.
Section 35 says the argument must be an array/optional element. This is inconsistent.

[mbeckerle]

Per discussion on DFDL WG Call 2024-01-11.

Current language in Section 35 prevents fn:count from being used to count the 'b' elements in this schema:

<element name="b" type="xs:int"/>
<element name="a" type="xs:int"/>
<element name="b" type="xs:int" minOccurs="0"/>

In XPath one could write fn:count(b) and it should return 1 or 2 if the Infoset is valid.

Assuming we want to allow this also in DFDL, then section 35 says the argument must be an array/optional element. This should be rephrased as referring to node sequences.

One advantage of requiring fn:count to be called only on array/optional elements is that a common user error can be detected - where the path is to a scalar element so that the count is always 1.

It seems this should not be an error. If fn:count takes a node sequence, and the node sequence is known to be of length 1, then per section 8.2.2 a warning may be issued.

[mbeckerle]

Is consistency with dfdl:occursIndex() an issue?

dfdl:occursIndex() is defined to return the index in the innermost array surrounding the context element where it is called.

fn:count of a node sequence and dfdl:occursIndex() are only consistent if the argument to fn:count is an array.

Consider this schema fragment:

<element name="b" type="xs:int" minOccurs="5" maxOccurs="5"/>
<element name="a" type="xs:int"/>
<element name="b" type="xs:int" minOccurs="5" maxOccurs="5"/>

In this case fn:count(b) would be 10, and the expression '{ b[i] }' the index would range from 1 to 10.

One would not be able to index into b using calculations based on dfdl:occursIndex() without adjusting for the fact that b is two arrays here, not one. This is easily worked around by just renaming the arrays/optional elements so they are all distinct names.

I think the conclusion is that no, dfdl:occursIndex() does not muddy the waters here, but keeping this comment to avoid revisiting this consideration.