mbeckerle commented on code in PR #1137:
URL: https://github.com/apache/daffodil/pull/1137#discussion_r1465508405
##########
daffodil-core/src/main/scala/org/apache/daffodil/core/dpath/Expression.scala:
##########
@@ -2329,6 +2342,11 @@ abstract class FunctionCallBase(
protected def checkArgArrayOrOptional(): Unit = {
lazy val isArrayOrOptional = expressions.head match {
case pe: PathExpression => pe.isPathToOneWholeArrayOrOptional
+ case ie: IfExpression => {
+ val tp = ie.thenPart
+ val ep = ie.elsePart
+ tp.isPathToOneWholeArrayOrOptional ||
ep.isPathToOneWholeArrayOrOptional
Review Comment:
Ok. I think the DFDL spec is not clear on whether fn:count must take a path
(not a DPath expression, a literally step/step/step thingy) or if it can be
if/then/else so long as the then/else are both arrays or both optionals.
I think this code doesn't work right for nested ifs. To get that to work
this would have to compose like the way the type system composes. I.e., the
```
tp.isPathToOneWholeArrayOrOptional || ep.isPathToOneWholeArrayOrOptional
```
(which should be && not ||) that would need to inductively be computed for
the then-part and else part.
Putting in that infrastructure, and then testing it sufficiently feels very
not worth it.
I think I'd rather keep it simpler and just say fn:count's argument must
literally be a path (i.e., relative or absolute path steps). It's a fair
interpretation of the DFDL spec to put this restriction in.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
