[DFDL-WG] Behavior of nilKind literalValue with respect to binaryNumberRep of packed

[Mike Beckerle]

Not sure I understand the mixture of the concepts of justification and
packed decimal here.

I usually think of packed decimal as fixed length and without padding.

Let me assume this example: 12345C is value 12345, 00000C is zero, and
00000F is the nil indicator.

So, bigEndian byte order, I think dfdl:nilvalue="%#r00;%#r00;%#r0F;" is
what I'd expect to see for a literalValue nilValue to match that.

I'm guessing some assumption in the above doesn't match your use case, so
please correct.

Mike Beckerle | OGF DFDL Workgroup Co-Chair | Owl Cyber Defense |
www.owlcyberdefense.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 Tue, Apr 14, 2020 at 2:59 PM Bradd Kadlecik <braddk at us.ibm.com> wrote:

> I think there is a problem when the literalValue is left-justified for
> binary data such as packed decimals. This seems problematic because a "0"
> value might be indicated by having the last byte be 0x0C for a signed
> numeric while a nil value might be desired to be understood by having the
> last byte be a 0x0F. In both cases, all preceding bytes are 0x00. In the
> case that the packed decimal is of variable length, there seems no way to
> represent this nil value unless it is understood that the fillByte is used
> for the area preceding the NilElementLiteralContent. Apologies if I might
> of missed some clarification made regarding this.
>
> Regards,
>
> *Bradd Kadlecik*
> z/TPF Development
> ------------------------------
> *Phone:* 1-845-433-1573
> *E-mail:* *braddk at us.ibm.com* <braddk at us.ibm.com>
> 2455 South Rd
> Poughkeepsie, NY 12601-5400
> United States
>
>
> --
>   dfdl-wg mailing list
>   dfdl-wg at ogf.org
>   https://www.ogf.org/mailman/listinfo/dfdl-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20200414/4286a8f6/attachment.html>