- dfdl-wg - lists.ogf.org

OGF DFDL WG Call on 2018-01-24 - cancelled but please read
by Steve Hanson 24 Jan '19

24 Jan '19

Apologies but Mike is not available. . Next call will be Feb 7th. Please note that we have new dial-in details for 2019 as we will be using webex, giving the opportunity to video conference & screen share if needed. When trialing this it worked best using the phone for voice rather than computer. https://ibm.webex.com/meet/smh Access code: 921 060 996 Join by video system Dial smh(a)ibm.webex.com You can also dial 173.243.2.68 and enter your meeting number. Join by phone 1-844-531-0958 United States Toll Free +44-20-37887817 United Kingdom Toll Access code: 921 060 996 Other numbers: Argentina Toll Free 08002665185 Australia Toll +61-280989107 Austria Toll 01206092053 Bahrain Toll Free 8000-6500 Belarus Toll Free 882000730095 Belgium Toll 022007632 Belize Toll Free 18000130860 Benin Toll 22961012502 Bolivia Toll Free 800-11-0374 Brazil Toll Free 0800-0474253 Brunei Toll Free 8014441 Bulgaria Toll Free 008001214493 Cambodia Toll Free 1800208961 Canada Toll Free 1-8445310958 Cayman Islands Toll Free 1-844-531-0958 Chile Toll Free 1230-020-0688 China Toll +86-4006015773 Colombia Toll Free 01-800-5-1-84797 Croatia Toll Free 800806054 Cyprus Toll Free 8009-0524 Czech Republic Toll 239018106 Denmark Toll 43310447 Dominican Republic Toll Free 1-844-531-0958 Ecuador Toll Free 1800000861 Estonia Toll Free 8000044833 Fiji Toll Free 008002594 Finland Toll 0972522226 France Toll +33-15-5698250 French Guiana Toll Free 800907946 Germany Toll +49-69-153253288 Ghana Toll Free 307084814 Greece Toll Free 00-800-11-003-5356 Guadeloupe Toll Free 0800912929 Hong Kong Toll 30163810 Hungary Toll 0617777350 India (Bengaluru) Toll 080-64800002 India (Chennai) Toll 044-64800002 India (Delhi) Toll 011-64800002 India (Hyderabad) Toll 040-64800002 India (Kolkata) Toll 033-64800002 India (Mumbai) Toll 022-64800002 India (Pune) Toll 020-64800002 Indonesia Toll Free 001-803-1-003-5356 Ireland Toll 015621276 Israel Toll Free 180-940-5356 Italy Toll +390287103980 Japan Toll +81-344774856 Korea (South) Toll +82-234831051 Latvia Toll Free 8000-5405 Liechtenstein Toll Free 0800110003 Lithuania Toll Free 880033471 Luxembourg Toll 3420808519 Macao Toll Free 85362626322 Macedonia Toll Free 080094374 Malaysia Toll 0377240231 Malta Toll Free 80062850 Mauritius Toll Free 8020440170 Mexico Toll Free 01-800-253-0545 Monaco Toll Free 80094247 Netherlands Antilles Toll Free 001-844-531-0958 Netherlands Toll +31-707007020 New Zealand Toll +64-99134336 Norway Toll 24055116 Pakistan Toll Free 0080090044298 Paraguay Toll Free 0098004410200 Peru Toll Free 0800-78-992 Philippines Toll Free 1-800-1-111-0950 Poland Toll Free 800080331 Portugal Toll Free 800-8-11079 Qatar Toll Free 0800100420 Reunion Toll Free 800916791 Romania Toll Free 800400917 Russia Toll Free 8003334845 Saudi Arabia Toll Free 8008500441 Saudi Arabia Toll Free 8008447531 Serbia Toll Free 0800191028 Singapore Toll 66224601 Slovakia Toll Free 0800134773 Slovenia Toll Free 080081893 South Africa Toll Free 0800333448 Spain Toll 918368565 Sri Lanka Toll Free 2145703 St. Pierre Toll Free 0805379684 Sweden Toll 0851989571 Switzerland Toll +41-43-5579221 Taiwan Toll 0226563014 Thailand Toll Free 1800-011-610 Turkey Toll Free 00800448825456 Ukraine Toll Free 0800609365 UAE Toll Free 80004448531 United Kingdom Toll +44-20-37887817 United States Toll +1-669-234-1178 United States Toll Free 1-844-531-0958 Uruguay Toll Free 000-411-003-5356 Venezuela Toll Free 0800-100-3557 Vietnam Toll Free 12280744 Vietnam Toll Free 12032529 Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

OGF DFDL Working Group call
by Steve Hanson 24 Jan '19

24 Jan '19

1 0

Cancelled: OGF DFDL Working Group call
by Steve Hanson 24 Jan '19

24 Jan '19

1 0

Test email
by Sill, Alan 17 Dec '18

17 Dec '18

Test after mail server cleanup, please ignore.

1 0

OGF DFDL WG Call on 2018-12-13 - cancelled
by Steve Hanson 12 Dec '18

12 Dec '18

Apologies but I have Q4 deadlines that mean I can't make the call. . Next call will be Jan 10th, I will send out calendar invites for 2019 Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

Cancelled: OGF DFDL Working Group Call
by Steve Hanson 12 Dec '18

12 Dec '18

1 0

Ambiguity or Correct ? Behavior of time zone in infoset for xs:date
by Mike Beckerle 11 Dec '18

11 Dec '18

I have a case where IBM DFDL and Daffodil differ, but I think both are correct so this is just a case where users have to tolerate variation in behavior: <dfdl:format calendarPatternKind="implicit" calendarTimeZone="UTC" /> <xs:element name="date1" type="xs:date" /> The data is "2010-12-30" The DFDL spec says the parser behavior is as for pattern "yyyy-MM-dd", which does not have any character for time zone information. So the time zone information is coming from the dfdl:calendarTimeZone="UTC" property. But this question isn't about the parsing/unparsing behavior. It's about what date/time components end up in the infoset and how those get projected into XML by different DFDL implementations. The problem is that there are multiple equivalent (according to XML/XSD and ISO 8601) representations in the infoset for this information. Ex: <date1>2010-12-30+00:00</date1> (Note: current Daffodil behavior) or <date1>2010-12-30Z</date1> (Note: current IBM DFDL behavior) I believe these are 100% equivalent according to ISO8601 which is the standard for date/time referenced from XML/XSD. If this is acceptable then there's no action here. It's just an equivalence that users have to expect. So I'm just raising this to get opinions. 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>

2 1

Action 292 - version 2 proposal for hexBinary with lengthUnits bits
by Mike Beckerle 07 Dec '18

07 Dec '18

Users want a way to express an arbitrary unaligned string of bits, with the appearance in the infoset being hexadecimal, not base 10. Right now the only way I can see to meet this requirement while retaining backward compatibility would be a new DFDL property. So here's the new idea: Property dfdl:hexBinaryRep with values 'bytes' or 'bits'. New property, so defaulting (with suppressible warning) to 'bytes' for backward compatibility in schemas not having the property. When set to 'bits', then type xs:hexBinary would behave just like xs:nonNegativeInteger, and all properties relevant to that type would be applicable, and any use of XSD length facets on such elements would be an SDE. The hexBinary string would be exactly same as if you took the numeric value for a nonNegativeInteger and instead of presenting it as base 10 digits, you use base 16 digits. 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 4

Latest OGF DFDL WG Call Minutes
by Steve Hanson 07 Dec '18

07 Dec '18

Please find minutes from the latest call at https://redmine.ogf.org/projects/dfdl-wg/news 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

clarification on behavior of DFDL encodingErrorPolicy='error' and pre-decoding by implementations
by Mike Beckerle 06 Dec '18

06 Dec '18

The DFDL spec isn't clear on when encodingErrorPolicy 'error' is allowed to cause an error, and when one must be suppressed, if the implementation pre-decodes data into characters. Example: Suppose you have what turns out to be 8 characters of text, followed by some binary data. Suppose a DFDL implementation happens to always try to fill a buffer of 64 decoded characters, just for efficiency reasons. Depending on what is in the binary data, this may parse the 8 characters of text without error, but subsequently hit a decode error, because it has strayed into binary data past the text. There is no actual decode error in the data stream, because parsing should determine there are only 8 characters of text, and then switch to parsing the binary data using binary means. The DFDL spec doesn't say this isn't allowed to cause a decode error. Perhaps it is implied somewhere? But I didn't find it. The DFDL spec does point out that for asserts/discriminators with testKind pattern, that pattern matching may cause decode errors. But again, suppose the regex matching library an implementation uses happens to pre-fetch and pre-decode a bunch of characters, but the regex matching library then finds a match that is quite short, and stops well before the characters that were pre-decoded that caused a decode error. It would seem to me that this sort of pre-decoding should not cause decode errors. but the DFDL spec doesn't state that explicitly. 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>

2 2