- dfdl-wg - lists.ogf.org

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

DFDL Workgroup Meeting 2024-03-14 - note time due to US change to daylight time
by Mike Beckerle 14 Mar '24

14 Mar '24

Note: Eastern time zone of US changed to DST last weekend. We are now UTC-5. This call is at 16:00 UTC, which is 11am EDT.US. Possibly a short call, but we should probably quickly review the ISO process. Also, I notice this new use of the acronym DFDL: http://signal.ee.psu.edu/research/dfdl.html There has been long standing DFDL use by a legal-related firm in Bangladesh, which really doesn't conflict with us. But this new usage is in a technology area so it gives me some concern. 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

2 2

*SPAM* DFDL trademarked?
by Mike Beckerle 13 Mar '24

13 Mar '24

Spam detection software, running on the system "mail.pglaf.org", has identified this incoming email as possible spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Does OGF have any sort of trade-mark or brand protection on the DFDL acronym? or even on "OGF DFDL"? I noticed this new use of the acronym DFDL: http://signal.ee.psu.edu/research/dfdl.html There is plenty of other use of DFDL already: Content analysis details: (5.5 points, 4.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: psu.edu] 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% [score: 0.4944] 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider [mbeckerle.dfdl[at]gmail.com] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature 0.9 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) 1.9 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% [cf: 100] -0.0 T_SCC_BODY_TEXT_LINE No description available. 0.0 FSL_BULK_SIG Bulk signature with no Unsubscribe 2.0 URI_DOTEDU Has .edu URI The original message was not completely plain text, and may be unsafe to open with some email clients; in particular, it may contain a virus, or confirm that your address can receive spam. If you wish to view it, it may be safer to save it to a file and open it with an editor.

2 1