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

Tue Apr 14 16:54:27 EDT 2020

Yes that works for fixed length but not variable length which is possible
for packed decimal with bigEndian.

 Regards,                                                                          

 Bradd Kadlecik                                                                    
 z/TPF Development                                                                 

 Phone: 1-845-433-1573                                                2455 South Rd 
 E-mail: braddk at us.ibm.com                                         Poughkeepsie, NY 
                                                                         12601-5400 
                                                                      United States 

From:	Mike Beckerle <mbeckerle.dfdl at gmail.com>
To:	Bradd Kadlecik <braddk at us.ibm.com>, DFDL-WG <dfdl-wg at ogf.org>
Date:	04/14/2020 03:56 PM
Subject:	[EXTERNAL] Re: [DFDL-WG] Behavior of nilKind literalValue with
            respect to binaryNumberRep of packed

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

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                                                2455 South Rd 
 E-mail: braddk at us.ibm.com                                         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/7c33d27b/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20200414/7c33d27b/attachment.gif>