[
https://issues.apache.org/jira/browse/DAFFODIL-2711?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mike Beckerle updated DAFFODIL-2711:
------------------------------------
Description:
The fn:count function, when called on a path expression that ends with a unique
scalar element, should be an SDE.
Such a call can only return value 1, or cause a processing error if the element
doesn't exist. Existance should be tested with fn:exists(...).
If the schema really does have
{code:java}
<element name="foo" minOccurs="0" .../>
<element name="bar" .../>
<element name="foo" maxOccurs="5" .../>{code}
and an expression has `fn:count(..../foo)` we already are giving an SDE about
query-style expressions not being supported.
If the schema does not have this issue (multiple declarations of same element
name), then fn:count() makes no sense when called on a scalar, and it should be
an SDE if the path is not for an array or optional element.
My experience thusfar is that use of fn:count( ...) with a non-array,
non-optional element path is always a mistake by the schema author.
Changing elements from array/optional to scalar is actually fairly common.
One decides rather than be an array, an element should instead contain the
array as a child element, but now any fn:count(....) referring to the original
array element is incorrect, as it now refers to the scalar element that
contains the array as a child element. The schema compiler needs to help find
these erroneous references.
Personally, I think calling fn:count(...) on a non-array/non-optional should be
an SDE, but....
(This added... Was a fragment sentence initially) ... it may have to be a SDW
with a tunable to make it an SDE, since we may find out that there are schemas
depending on this returning 1 when called on scalar elements that would be
broken by making it an SDE.
I suggest just making this an SDE first, and then we can see if it needs to be
backed off to an SDW for some schemas.
was:
The fn:count function, when called on a path expression that ends with a unique
scalar element, should be an SDE.
Such a call can only return value 1, or cause a processing error if the element
doesn't exist. Existance should be tested with fn:exists(...).
If the schema really does have
{code:java}
<element name="foo" minOccurs="0" .../>
<element name="bar" .../>
<element name="foo" maxOccurs="5" .../>{code}
and an expression has `fn:count(..../foo)` we already are giving an SDE about
query-style expressions not being supported.
If the schema does not have this issue (multiple declarations of same element
name), then fn:count() makes no sense when called on a scalar, and it should be
an SDE if the path is not for an array or optional element.
My experience thusfar is that use of fn:count( ...) with a non-array,
non-optional element path is always a mistake by the schema author.
Changing elements from array/optional to scalar is actually fairly common.
One decides rather than be an array, an element should instead contain the
array as a child element, but now any fn:count(....) referring to the original
array element is incorrect, as it now refers to the scalar element that
contains the array as a child element. The schema compiler needs to help find
these erroneous references.
Personally, I think calling fn:count(...) on a non-array/non-optional should be
an SDE, but
> fn:count( non-array ) must issue SDE
> -------------------------------------
>
> Key: DAFFODIL-2711
> URL: https://issues.apache.org/jira/browse/DAFFODIL-2711
> Project: Daffodil
> Issue Type: Improvement
> Components: Front End
> Affects Versions: 3.3.0
> Reporter: Mike Beckerle
> Assignee: Peter Katlic
> Priority: Major
> Labels: beginner
>
> The fn:count function, when called on a path expression that ends with a
> unique scalar element, should be an SDE.
> Such a call can only return value 1, or cause a processing error if the
> element doesn't exist. Existance should be tested with fn:exists(...).
> If the schema really does have
> {code:java}
> <element name="foo" minOccurs="0" .../>
> <element name="bar" .../>
> <element name="foo" maxOccurs="5" .../>{code}
> and an expression has `fn:count(..../foo)` we already are giving an SDE about
> query-style expressions not being supported.
> If the schema does not have this issue (multiple declarations of same element
> name), then fn:count() makes no sense when called on a scalar, and it should
> be an SDE if the path is not for an array or optional element.
> My experience thusfar is that use of fn:count( ...) with a non-array,
> non-optional element path is always a mistake by the schema author.
> Changing elements from array/optional to scalar is actually fairly common.
> One decides rather than be an array, an element should instead contain the
> array as a child element, but now any fn:count(....) referring to the
> original array element is incorrect, as it now refers to the scalar element
> that contains the array as a child element. The schema compiler needs to help
> find these erroneous references.
>
> Personally, I think calling fn:count(...) on a non-array/non-optional should
> be an SDE, but....
> (This added... Was a fragment sentence initially) ... it may have to be a SDW
> with a tunable to make it an SDE, since we may find out that there are
> schemas depending on this returning 1 when called on scalar elements that
> would be broken by making it an SDE.
> I suggest just making this an SDE first, and then we can see if it needs to
> be backed off to an SDW for some schemas.
>
>
>
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
