An additional thought here. The DFDL spec says that to be potentially trailing an element must have a possible zero-length representation. So, an element such as of type int, which is not nillable with zero length, not empty with default value with zero length, such an element cannot have a zero-length representation. If one of these elements is in an all-optional minOccurs=0 array at the end of a sequence, then trailing extra separators would NOT be acceptable regardless of trailingEmpty being lax, because the element is not potentially trailing. However, elsewhere it says that absent (therefore missing) elements are never created for optional elements. Zero length for such an element means "absent" and so missing. And that means not put into the infoset which suggests that they are acceptable and ignored (though counted towards maxOccurs positions in a positional sequence) This seems completely ambiguous to me. Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php> On Fri, Jul 20, 2018 at 1:03 PM, Mike Beckerle <mbeckerle.dfdl@gmail.com> wrote:
I have been trying to rationalize the definitions in the DFDL spec for separated sequences.
I cannot find a way to express something very simple: A repeating element with minOccurs non-zero-length elements with separators required, and up to maxOccurs (or unbounded) non-zero-length elements with separators are allowed. This means separators can never be adjacent anywhere in the corresponding data stream (except if escaped, or hidden inside say a fixed-length string inside a complex type element). Adjacent delimiters would be a parse error.
I expected this to be occursCountKind 'implicit' with separatorSuppressionPolicy 'never', but that appears to mean that maxOccurs must be bounded and there are always exactly maxOccurs separators, the latter of which (maxOccurs - minOccurs of them) can be empty strings, meaning optional elements will not be created for them.
All the other 3 separator suppression policies absorb adjacent separators, except for trailingEmptyStrict doesn't absorb them at the end of the group.
There doesn't seem to be a way to be strict about the format and speculatively parse only non-zero-length elements requiring each optional occurance to appear with associated separator. I.e., no trailing adjacent separators, and no adjacent separators in the middle or beginning either.
Are we missing separatorSuppressionPolicy='neverEmpty' or 'anyEmptyStrict' perhaps?
Comments?
...mikeb
Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology | www.tresys.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php>