There are unintended consequences from using an xs:nonNegativeInteger argument to dfdl:occursIndex.

Specifically, it allows the number of steps upward to be computed dynamically e.g., dfdl:occursIndex(../foo/bar/nstepsToArray) or even dfdl:occursIndex($x) where x is some DFDL variable of integer type.

Ooops.

This is distinctly more powerful (in a bad way) than if one instead requires a path expression to an actual array node. It completely defeats static analysis such as XPath StaticTypeFeature kind of analysis, which is really important and valuable in DFDL since unlike other applications of XPath, we always have a schema.

If we instead allow a path argument which must lead upward to an enclosing array, then that path expression can be statically typed, so it becomes legal to reject paths that go up past the root as non-type-able, when an implementation can detect this.

Our prior discussion of nonsense paths such as dfdl:occursIndex(../foo/..) where there is no foo peer element in the schema, those are all non-type-able, so a DFDL implementation is free to reject them statically or dynamically. So we really don't have to worry about them and try to re-jigger the arg to an integer so as to avoid them.

My conclusion from this is we should go back to the argument being a path expression, that must lead to an enclosing array. It can be just "." if the current element is itself an array.

Comments?