Behavior of nilKind literalValue with respect to binaryNumberRep of packed
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@us.ibm.com Poughkeepsie, NY 12601-5400 United States
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@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@us.ibm.com* <braddk@us.ibm.com> 2455 South Rd Poughkeepsie, NY 12601-5400 United States
-- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg
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@us.ibm.com Poughkeepsie, NY 12601-5400 United States From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: Bradd Kadlecik <braddk@us.ibm.com>, DFDL-WG <dfdl-wg@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@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@us.ibm.com Poughkeepsie, NY 12601-5400 United States -- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg
Can you give what the bytes look like for typical values of various sizes small and large, how their length is determined, and what a nil value looks like in bytes? 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 4:54 PM Bradd Kadlecik <braddk@us.ibm.com> wrote:
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 *E-mail:* *braddk@us.ibm.com* <braddk@us.ibm.com> 2455 South Rd Poughkeepsie, NY 12601-5400 United States
[image: Inactive hide details for Mike Beckerle ---04/14/2020 03:56:45 PM---Not sure I understand the mixture of the concepts of justif]Mike Beckerle ---04/14/2020 03:56:45 PM---Not sure I understand the mixture of the concepts of justification and packed decimal here.
From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: Bradd Kadlecik <braddk@us.ibm.com>, DFDL-WG <dfdl-wg@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* <http://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@us.ibm.com* <braddk@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@us.ibm.com* <braddk@us.ibm.com> 2455 South Rd Poughkeepsie, NY 12601-5400 United States
-- dfdl-wg mailing list *dfdl-wg@ogf.org* <dfdl-wg@ogf.org> *https://www.ogf.org/mailman/listinfo/dfdl-wg* <https://www.ogf.org/mailman/listinfo/dfdl-wg>
There is no explicit control over justification and trimming for binary data. For a specific type of binary data, it is what it is. Packed decimals for example are always right-justified. I don't think interpreting x00x00x0F as a nil value is a good idea. Typically this is unsigned zero, but it is a valid number and not an out-of-type value. I can see that one might want to use xFFFFFFF or x000000 as nil, as these values are often blatted into storage by (eg COBOL) programs and both are out-of-type (although you can handle the latter as zero using dfdl:binaryPackedSignCodes property). The way you handle these as nil is using dfdl:nilLiteralCharacter, set to "%#rFF" or "%#r00" respectively, which handles the variable length. There is no way to provide a nil literal value for a variable length binary element, because no trimming takes place. Regards Steve Hanson IBM Hybrid Integration, Hursley, UK Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh@uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890 Note: I work Tuesday to Friday From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: Bradd Kadlecik <braddk@us.ibm.com> Cc: DFDL-WG <dfdl-wg@ogf.org> Date: 14/04/2020 23:57 Subject: [EXTERNAL] Re: [DFDL-WG] Behavior of nilKind literalValue with respect to binaryNumberRep of packed Sent by: "dfdl-wg" <dfdl-wg-bounces@ogf.org> Can you give what the bytes look like for typical values of various sizes small and large, how their length is determined, and what a nil value looks like in bytes? 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 4:54 PM Bradd Kadlecik <braddk@us.ibm.com> wrote: 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 E-mail: braddk@us.ibm.com 2455 South Rd Poughkeepsie, NY 12601-5400 United States Mike Beckerle ---04/14/2020 03:56:45 PM---Not sure I understand the mixture of the concepts of justification and packed decimal here. From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: Bradd Kadlecik <braddk@us.ibm.com>, DFDL-WG <dfdl-wg@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@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@us.ibm.com 2455 South Rd Poughkeepsie, NY 12601-5400 United States -- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg -- dfdl-wg mailing list dfdl-wg@ogf.org https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ogf.org_mailman_listinfo_dfdl-2Dwg&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=AJa9ThEymJXYnOqu84mJuw&m=Qr-8381c5wkjlofZazpg_iHN9vydMq93pUeflWJsX30&s=Ckk_9cpxAjGgSPkKeR7UbiNoONox8VS4yUV9dNewGBc&e= Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
participants (3)
-
Bradd Kadlecik -
Mike Beckerle -
Steve Hanson