- dfdl-wg - lists.ogf.org

Cancelled: OGF DFDL Working Group call
by Steve Hanson 06 Mar '17

06 Mar '17

1 0

OGF DFDL WG Call Minutes 2017-02-21
by Steve Hanson 21 Feb '17

21 Feb '17

Please find minutes from the above call at https://redmine.ogf.org/dmsf_files/13550?download= Next call March 7th Regards Steve Hanson IBM Hybrid Integration Architect, IBM DFDL, Co-Chair, OGF DFDL Working Group smh(a)uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890

1 0

OGF DFDL WG Call Agenda 2017-02-21
by Steve Hanson 21 Feb '17

21 Feb '17

Please find agenda for call on Redmine at https://redmine.ogf.org/dmsf_files/13550?download= Regards Steve Hanson IBM Hybrid Integration Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh(a)uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890

1 0

Confirmed: OGF DFDL Working Group call (21 Feb 15:00 GMT in IBM: Hursley DE3S09)
by Steve Hanson 21 Feb '17

21 Feb '17

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

1 0

OGF DFDL WG Call Minutes 2017-02-07
by Steve Hanson 07 Feb '17

07 Feb '17

Please find minutes from the above call at https://redmine.ogf.org/dmsf_files/13549?download= Next call Feb 21st. Regards Steve Hanson Architect, IBM DFDL, Co-Chair, OGF DFDL Working Group IBM SWG, Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

OGF DFDL Working Group call
by Steve Hanson 07 Feb '17

07 Feb '17

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

1 0

OGF DFDL WG Call Agenda 2017-02-07
by Steve Hanson 07 Feb '17

07 Feb '17

Please find agenda for call on Redmine at https://redmine.ogf.org/dmsf_files/13549?download= Regards Steve Hanson IBM Integration Bus, Hursley, UK Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh(a)uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890

1 0

Re: [DFDL-WG] clarification needed - choice with both dispatch and discriminator
by Andrew Edwards 27 Jan '17

27 Jan '17

1 0

clarification needed - choice with both dispatch and discriminator
by Mike Beckerle 27 Jan '17

27 Jan '17

Section 15.1.2 says you can have both dfdl:choiceBranchKey and a discriminator on a choice branch. But it doesn't clarify what the meaning of having both is. My assumption is that if you have both, the choice is resolved by the choiceDispatchKey/choiceBranchKey, so any discriminator would be about some surrounding point of uncertainty outside the choice. I wanted to confirm this is the intention. The alternative semantics would be that the discriminator is redundant, and so if it evaluates to true that means nothing at all since the choice branch has already been discriminated by the choiceDispatchKey/choiceBranchKey. If the discriminator evaluates to false, or errors when it evaluates, that would be a parse error that would cause the entire choice to fail. Comments? 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>

3 2

suggest: need hexBinary with lengthUnits 'bits' with length not a multiple of 8.
by Mike Beckerle 27 Jan '17

27 Jan '17

We have users who have binary blobs the size of which is given in bits, and these blobs are not a multiple of 8 long. Today the DFDL spec doesn't allow hexBinary to have lengthUnits 'bits'. I am wondering if this restriction should be lifted. XSD constrains hexBinary to always have an even number of Hex digits, so we would have to do the same. So for an example, a 17 bit long hexBinary containing all 1 bits would be FFFF80 Erratum 5.15 extends the types that are allowed to have length in bits to include packed calendars. So there is precedent for opening this restriction up if need arises. I claim we need to (a) allow length units bits for all types (b) restrict the length to have to be 32-bits or 64-bits only, for types xs:float and xs:double when representation 'binary' (c) restrict packed decimal to have lengths be a multiple of 4 bits (when specified in units 'bits') All other restrictions should be lifted as those restrictions just cause problems in some formats. For example 12.3.7.2.5 Specifies that binary calendars must be 4 bytes or 8 bytes exactly, and cannot be specified in units 'bits'. This is just a mistake in DFDL. I have even seen binary calendars with 33 bits length. (seconds since 1-1-1970 representation aka binarySeconds) That additional bit extends the end time substantially. These restrictions were put into DFDL because our experience of many bit-granularity formats was limited. What we've found is that there are plenty of data formats where the notion of a "byte" is simply absent. Nothing uses multiples of 8 bits for anything, and nothing is measured in those units. It's always measured in bits. Even for things like float and double, which have impliicit lengths of 4 and 8 bytes respectively, many specifications will express those as 32 bits or 64 bits. Having to divide by 8 just makes the DFDL schema awkward. Similarly in these formats strings are given length in bits. 448 bits worth of 7-bit packed ascii characters is 64 characters, occupying 56 bytes, but the spec uses 448. These changes are all backward-compatible. They make legal property settings that previously had no meaning and caused SDEs. Discussion? 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>

2 2