- dfdl-wg - lists.ogf.org

Reminder: Agenda topics for Thursday May 8 DFDL call
by Mike Beckerle 08 May '24

08 May '24

I believe the requested agenda topic for the May 8 call was discussion of DFDL 2.0 and/or DFDL 1.1? Please circulate emails about topics in that area you'd like to discuss on the call, or generally. There is a problem called the "second system effect" I think which is when version 2.0 never happens because the team wants to fix every single thing wrong with version 1.0, and perfectionism sets in. We want to avoid that. There is also a role for what I would call "standard profiles" which are knobs to turn to tell a DFDL processor that you want to limit your DFDL usage so that your schemas will have certain standard behaviours. An example is to disallow elements to be distinguished only by namespace, so that the DFDL schema can be used to convert data to/from JSON or other data frameworks where elements have only names, and there is no notion of namespaces for names. We've run into this in JSON and a major integration of Daffodil with Apache Drill. DFDL users would benefit from a way to say "keep me out of namespace troubles" like that. Mike Beckerle Apache Daffodil PMC | daffodil.apache.org OGF DFDL Workgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl Owl Cyber Defense | www.owlcyberdefense.com

2 2

Re: [DFDL-WG] [EXTERNAL] Fwd: proof text for ISO/IEC 23415
by Mike Beckerle 19 Apr '24

19 Apr '24

Lisa, We found some additional issues with the previously sent ISO DFDL PDF. Besides the problem with the footers being cut off (already reported) we found: - Links do not work: - Table-of-contents entries do not let you navigate to the sections. - Internal links like "[XML]" to the references section do not work. - Hyperlink text in the references sections do not work. - The page margins are inconsistent. Viewed with 2 pages on screen side by side, the left pages have narrow left margin in comparison to right pages. - Tables 46 and 47 in Sections 14.2.1 and 14.2.1 break across page boundaries. This makes them very hard to interpret, and while some large tables can split across pages normally, for these specific tables, the page boundary makes it very hard to understand them. Manual breaks should be inserted to avoid this. - Table 48 in Section 14.2.3 does not have a bad-break currently. But this table is also one that a page-break across it needs to be avoided. Please forward these to the right parties who are preparing the ISO/IEC version. Thank you Mike Beckerle OGF DFDL Workgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl Apache Daffodil PMC | daffodil.apache.org 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 Fri, Mar 8, 2024 at 9:42 AM Lisa Rajchel <lrajchel(a)ansi.org> wrote: > Mike, > > I have sent your comment to ISO and now it is their hands. No one has > asked for anything more from you. I will keep you posted. > > Best > Lisa > > Sent with BlackBerry Work > (www.blackberry.com) > > > *From: *Mike Beckerle <mbeckerle.dfdl(a)gmail.com> > *Date: *Friday, Mar 08, 2024 at 9:23 AM > *To: *Lisa Rajchel <lrajchel(a)ansi.org> > *Subject: *[EXTERNAL] Fwd: [DFDL-WG] proof text for ISO/IEC 23415 > > Lisa, > > I am following up on this need for another spin on the DFDL 23415 official > ISO version. > > As far as I know this is out of our hands, meaning the workgroup on DFDL. > However, we have a workgroup meeting this week, I am wondering if there are > any actions we need or could take to help get the 23415 through the process > and fully published. > > Please advise > > Thank you > > > Mike Beckerle > OGF DFDL Workgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl > Apache Daffodil PMC | daffodil.apache.org > 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> > > > > ---------- Forwarded message --------- > From: Steve Hanson <smhdfdl(a)gmail.com> > Date: Sun, Feb 25, 2024 at 5:10 AM > Subject: Re: [DFDL-WG] proof text for ISO/IEC 23415 > To: Mike Beckerle <mbeckerle.dfdl(a)gmail.com> > Cc: Lisa Rajchel <lrajchel(a)ansi.org>, DFDL-WG <dfdl-wg(a)ogf.org> > > > It looks like the footer is being cut off in order to accommodate the > three lines of licence text in every header. > > Regards > Steve > > On Sat, Feb 24, 2024 at 10:39 PM Mike Beckerle <mbeckerle.dfdl(a)gmail.com> > wrote: > >> Lisa, >> >> The footer is cut off on every page of this PDF, making it impossible to >> see the page numbers. >> >> I have not so far found any problem with the content of the pages, but >> this problem with the page footers does require a re-spin of the PDF, and >> if the page sizes change the table-of-contents will need its page numbers >> updated. >> >> -mike >> >> Mike Beckerle >> OGF DFDL Workgroup Co-Chair | >> www.ogf.org/ogf/doku.php/standards/dfdl/dfdl >> Apache Daffodil PMC | daffodil.apache.org >> 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, Feb 20, 2024 at 4:32 AM Lisa Rajchel <lrajchel(a)ansi.org> wrote: >> >>> Good morning, >>> >>> >>> >>> Attached please find the proof text for ISO/IEC 23415. Please confirm, >>> by March 18, 2024, that the content is ready for publication. >>> >>> >>> >>> Best >>> >>> Lisa >>> >> -- >> dfdl-wg mailing list >> dfdl-wg(a)lists.ogf.org >> https://lists.ogf.org/mailman/listinfo/dfdl-wg >> > > > This e-mail is intended exclusively for the individual or entity to which > it is addressed or otherwise directed. This e-mail (and its attachments) > may contain confidential, proprietary or privileged information, and > unauthorized disclosure or use of such information is prohibited absent > express authorization of the sender. If you receive this e-mail in error, > please notify the sender and delete this e-mail from your system. >

1 3

Call minutes for 2024-04-18
by Mike Beckerle 19 Apr '24

19 Apr '24

Call minutes are here: https://github.com/OpenGridForum/DFDL/blob/master/calls/2024/2024-04-18_DFD… A proof-copy of the ISO version of the DFDL spec is here: https://github.com/OpenGridForum/DFDL/blob/master/ISO-process/ISO_IEC%20234… The name reflects that the file is watermarked and for A.Sill/M.Beckerle, not for general distribution. Mike Beckerle Apache Daffodil PMC | daffodil.apache.org OGF DFDL Workgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl Owl Cyber Defense | www.owlcyberdefense.com

3 7

Agenda for Call 2024-04-18 11:00-04:00
by Mike Beckerle 17 Apr '24

17 Apr '24

See https://github.com/OpenGridForum/DFDL/pull/55/files#diff-c18a5ebbb168df129b… Mike Beckerle Apache Daffodil PMC | daffodil.apache.org OGF DFDL Workgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl Owl Cyber Defense | www.owlcyberdefense.com

1 0

Fwd: [ANNOUNCE] Apache Daffodil 3.7.0 Released
by Mike Beckerle 15 Apr '24

15 Apr '24

---------- Forwarded message --------- From: Steve Lawrence <slawrence(a)apache.org> Date: Wed, Apr 10, 2024, 7:16 AM Subject: [ANNOUNCE] Apache Daffodil 3.7.0 Released To: <dev(a)daffodil.apache.org> The Apache Daffodil community is pleased to announce the release of version 3.7.0. This release includes a number of bug fixes and performance improvements. Detailed release notes and downloads are available at: https://daffodil.apache.org/releases/3.7.0/ Apache Daffodil is an open-source implementation of the DFDL specification that uses DFDL data descriptions to parse fixed format data into an infoset. This infoset is commonly converted into XML or JSON to enable the use of well-established XML or JSON technologies and libraries to consume, inspect, and manipulate fixed format data in existing solutions. Daffodil is also capable of serializing or "unparsing" data back to the original data format. The DFDL infoset can also be converted directly to/from the data structures carried by data processing frameworks so as to bypass any XML/JSON overheads. For more information about Daffodil visit: https://daffodil.apache.org/ Regards, The Apache Daffodil Team

1 0

Updated invitation with note: DFDL Workgroup - DFDL Spec Issues and Actions @ Thu Apr 18, 2024 11am - 12pm (EDT) (dfdl-wg@ogf.org)
by Mike Beckerle 29 Mar '24

29 Mar '24

This event has been updated with a note: "Rescheduled just this meeting. " Changed: time DFDL Workgroup - DFDL Spec Issues and Actions Thursday Apr 18, 2024 ⋅ 11am – 12pm Eastern Time - New York Location Google Meet https://www.google.com/maps/search/Google+Meet?hl=en Join with Google Meet https://meet.google.com/ifg-hknz-ysw?hs=224 Please send email to open discussions and add agenda for this meeting. If there are no specific topics I will cancel the meeting. Organizer Mike Beckerle mbeckerle.dfdl(a)gmail.com Guests Mike Beckerle - organizer frostmar(a)uk.ibm.com Mike Beckerle - optional smhdfdl(a)gmail.com - optional jens.jensen(a)stfc.ac.uk - optional alan.sill(a)ttu.edu - optional mbeckerle(a)owlcyberdefense.com - optional braddk(a)us.ibm.com - optional dfdl-wg(a)ogf.org - optional wiloneil(a)uk.ibm.com - optional wolfgang.ziegler(a)z-rands.de - optional View all guest info https://calendar.google.com/calendar/event?action=VIEW&eid=amJnNXNxYzdwZmlo… Reply for dfdl-wg(a)ogf.org and view more details https://calendar.google.com/calendar/event?action=VIEW&eid=amJnNXNxYzdwZmlo… Your attendance is optional. ~~//~~ Invitation from Google Calendar: https://calendar.google.com/calendar/ You are receiving this email because you are an attendee on the event. To stop receiving future updates for this event, decline this event. Forwarding this invitation could allow any recipient to send a response to the organizer, be added to the guest list, invite others regardless of their own invitation status, or modify your RSVP. Learn more https://support.google.com/calendar/answer/37135#forwarding

1 0

Reschedule Next Call (was April 11) - Mike Beckerle can't make it
by Mike Beckerle 29 Mar '24

29 Mar '24

I just realized I am on vacation that week. I would like to reschedule for April 18th. I will move the calendar invite, and we'll have the call or not depending on whether others accept the invite. Mike Beckerle Apache Daffodil PMC | daffodil.apache.org OGF DFDL Workgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl Owl Cyber Defense | www.owlcyberdefense.com

1 0

xs:dateTime constructor - spec bug - erratum on the erratum
by Mike Beckerle 29 Mar '24

29 Mar '24

This will probably require an erratum. On 2023-06-13 we applied errata to the DFDL spec, and one of these errata fixes is actually incorrect. The correction says: Section 18.5.1 the xs:dateTime function takes 2 arguments, an xs:date and xs:time. This is not consistent with the XPath constructor function of that name, which takes a single argument: - xs:dateTime($arg as xs:anyAtomicType?) as xs:dateTime? DFDL spec also describes an fn:dateTime function - same signature - two arguments, in that same section (table 57). This is correct and consistent with XPath. Mike Beckerle Apache Daffodil PMC | daffodil.apache.org OGF DFDL Workgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl Owl Cyber Defense | www.owlcyberdefense.com

1 0

Re: [DFDL-WG] ICU and dfdl:textNumberPattern issue
by Mike Beckerle 14 Mar '24

14 Mar '24

Reporting back to the DFDL WG on how this issue got resolved on the Daffodil project. The issue came up in the NITF data format. The schema is on github DFDLSchemas site. Here is the long issue: https://github.com/DFDLSchemas/NITF/issues/19 read intro then skip to this comment: https://github.com/DFDLSchemas/NITF/issues/19#issuecomment-1889110915 Also related: https://issues.apache.org/jira/browse/DAFFODIL-2870 which is is a open issue to warn about any ICU negative pattern chars that are ignored. Also related: https://github.com/apache/daffodil/pull/1139 which is a related fix. On Thu, Mar 14, 2024 at 11:55 AM Steve Hanson <smhdfdl(a)gmail.com> wrote: > Mike, this is the thread about the negative pattern length issue. > > On Mon, Jan 15, 2024 at 11:10 AM Steve Hanson <smhdfdl(a)gmail.com> wrote: > >> I seem to recall hitting the same problem with X12 fixed length numerics >> which could be positive or negative. If I get time before our next call >> I'll re-familiarise myself with the X12 issue and what I did to work round >> it. >> >> Regards >> Steve >> >> On Thu, Jan 11, 2024 at 6:25 PM Mike Beckerle <mbeckerle(a)apache.org> >> wrote: >> >>> We've run into an issue with dfdl:textNumberPattern, which is an ICU >>> number pattern. I'll discuss here, and then suggest this is a fix needed in >>> DFDL generally, but we should discuss that hypothesis. >>> >>> The motivating example is fixed length 5 character integer text data. >>> The data ranges from -9999 to 99999. Note that the minus sign uses up one >>> of the 5 characters that can be a digit for positive values. >>> >>> Consider the value -123 and textNumberPattern of "00000;-0". The value >>> unparses as -00123 which is length 6 so too long. >>> >>> The padding feature of ICU number patterns can be used to "fix" this. >>> Consider textNumberPattern="*0####0". The "*0" notation means to use 0 as >>> the padding character to replace the "#" when needed. >>> Now the value 123 unparses as 00123 but ... here's the problem.... -123 >>> unparses as 0-123. Notice how the zero padding is before the minus sign >>> when we wanted it to appear after. >>> >>> This problem is caused by ICU taking nearly all the information from the >>> positive part of the textNumberPattern. The negative part of the pattern, >>> if it exists, is used only to define the affix (prefix or suffix or both) >>> that indicate negative values. >>> >>> The problem is that positive numbers commonly have no affix, so the >>> position of padding characters relative to the affix cannot always be >>> determined from the positive pattern alone. >>> >>> Hence, if textNumberPattern specifies a pad character before the number >>> pattern and without a positive prefix, then ICU defaults to a pad position >>> of PAD_BEFORE_PREFIX with no way to change it with just the pattern. >>> >>> This behavior is reasonable for most cases, like when the pad character >>> is a space. However, if the pad character in textNumberPattern is '0', then >>> negative numbers are padded with a '0' before the negative sign. So we get >>> the errant behavior where a pattern of "*0####0" unparses -123 to "0-123". >>> This is very unlikely to be what the user wants with this pattern. >>> >>> Now suppose the positive pattern required a prefix "+" sign. The >>> textNumberPattern of "+*0####0" works properly because ICU determines that >>> the padding is PAD_AFTER_PREFIX from the positive pattern where the "*0" is >>> after the "+" prefix. >>> >>> The proposed fix to this issue that we're implementing in Daffodil is >>> this: If both negative and positive patterns define padding on the same >>> affix, and the positive pattern has an empty string for that affix, then we >>> use the pad position from the negative pattern. In all other cases, the pad >>> character in the negative pattern is ignored following usual ICU behavior. >>> >>> For example, a textNumberPattern of "*0####0;-*00" formats a negative >>> number with zero padding after the hyphen, whereas normal ICU behavior >>> would ignore the negative pattern and zero pad before the hyphen. >>> >>> >>> I would suggest this is something that is a needed fix in general for >>> DFDL. >>> >>> >>> The workaround when you have the fixed length number use case (-9999 to >>> 99999) is very ugly, treating the minus sign as an initiator and creating >>> separate elements for positive and negative values, or punting on this >>> integer and treating the whole thing as a string. >>> >>> >>> Arguably, this might be considered an ICU bug, but ICU's API can be used >>> to specify the PAD_AFTER_PREFIX behavior, so it's not like ICU doesn't let >>> you achieve the needed behavior, it's just not something that can be >>> achieved using only the ICU pattern string. But ICU maintainers may or may >>> not consider this to be a bug. >>> >>> >>> Mike Beckerle >>> Apache Daffodil PMC | daffodil.apache.org >>> OGF DFDL Workgroup Co-Chair | >>> www.ogf.org/ogf/doku.php/standards/dfdl/dfdl >>> Owl Cyber Defense | www.owlcyberdefense.com >>> >>> >>> -- >>> dfdl-wg mailing list >>> dfdl-wg(a)lists.ogf.org >>> https://lists.ogf.org/mailman/listinfo/dfdl-wg >>> >>

2 1

Resolution of the ICU-related "#.##" textNumberPattern with 0.12
by Mike Beckerle 14 Mar '24

14 Mar '24

I cannot find the original email thread about this, but for records/posterity... The issue is described in this JIRA ticket: https://issues.apache.org/jira/browse/DAFFODIL-2859 That was closed as "Won't Fix". In short, why does 0.12 format as "0.12" instead of ".12" when textNumberPattern is "#.##". It would seem that "#.##" would mean the leading 0 is optional. But it doesn't. ICU chooses the minimum number of integer digits to be 1 even when the textNumberPattern has "#" before the decimal point. ICU team did not resolve this either way, the bug I reported there remains open: https://unicode-org.atlassian.net/browse/CLDR-17309 But, this would be a significant change in ICU behavior, so probably cannot change in ICU without requiring a switch be thrown to enable it. Mike Beckerle Apache Daffodil PMC | daffodil.apache.org OGF DFDL Workgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl Owl Cyber Defense | www.owlcyberdefense.com

1 0