[DFDL-WG] Clarification needed: stricter separator suppresssion policy

[Mike Beckerle]

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 at 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>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20180720/3edefde6/attachment-0001.html>