[DFDL-WG] Missing restriction in 'endOfParent' length kind ??

[Mike Beckerle]

I think we're missing a restriction for 'endOfParent'

Restriction: If an element has lengthKind 'endOfParent', then it's
lengthUnits must be the same as the lengthUnits of the parent. SDE
otherwise.

Rationale:

If a string has fixed length, and  lengthUnits 'bytes' then currently we
require the textStringPadCharacter to be a single-byte character. This
prevents issues where there are bytes that can't be filled in by a pad
character nor trimmed as a pad character.

But if the string has 'endOfParent' length, the string could have
lengthUnits 'characters', encoding utf-16, and would then typically have a
2-byte pad character. But the enclosing parent could have lengthUnits bytes
and an odd fixed/specified length. Hence, a byte could be left over that
cannot be filled with a pad character, nor trimmed as a pad character.

It is noisome to have this corner case/excess byte problem for
'endOfParent' when we have so cleverly dodged it for all the
specified-length kinds with the restriction to single-byte pad characters
when lengthUnits is bytes.

There is language in the spec about dealing with these trailing RightFill
or ElementUnused regions. With the above restriction I believe RightFill
becomes associated only with the hexBinary type being extended to fill out
a specified-length or endOfParent box. The much more complex issue of
RightFill appearing after text characters remains, but outside of the
context where padding/trimming are involved.

It is really problematic language. Frought with possibilities for
misinterpretation. To me it is very preferable to just make 'endOfParent'
consistent with other constraints associated with padding for
specified-length elements.




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/20140424/6d2ead9c/attachment.html>