[DFDL-WG] argument for dfdl:occursIndex( path exp ) versus integer argument

[Mike Beckerle]

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?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20140904/4c3e0972/attachment.html>