- dfdl-wg - lists.ogf.org

Updated invitation with note: DFDL Workgroup - DFDL Spec Issues and Actions @ Wed Feb 7, 2024 11am - 12pm (EST) (dfdl-wg@ogf.org)
by Mike Beckerle 25 Jan '24

25 Jan '24

This event has been updated with a note: "I need to change this one call to a different day. I've chosen to try moving it to Wednesday Feb 7. " Changed: time DFDL Workgroup - DFDL Spec Issues and Actions Wednesday Feb 7, 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

DFDL == ISO/IEC DIS 23415
by Mike Beckerle 22 Jan '24

22 Jan '24

Links: https://www.iso.org/standard/87444.html says we're in under development status https://www.iso.org/obp/ui/en/#iso:std:iso-iec:23415:dis:ed-1:v1:en 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

ISO JTC1 ballot approved !
by Mike Beckerle 22 Jan '24

22 Jan '24

Looks like ISO JTC1 has approved our PAS application. I am not sure what next steps are. Presumably we'll have to create a version of the spec in ISO preferred formatting style, and our branding may need to change some. ---------- Forwarded message --------- From: Wolfgang Ziegler <wolfgang.ziegler(a)z-rands.de> Date: Mon, Jan 22, 2024 at 3:50 AM Subject: Re: Any word from ISO JTC1? To: <mbeckerle(a)apache.org> Cc: GFSG Group <gfsg(a)ogf.org> Dear Mike, we finally received the notification from the JTC1 secretary. "Sorry for the late notification. The DIS ballot was approved 100%. I can now ask ISO to publish. I will let you know if I need anything from you." Congratulations! We'll get in contact with you, if ISO needs something additional for the publishing process. Best regards Wolfgang Am 09.01.24 um 22:50 schrieb Wolfgang Ziegler: > Dear Mike, > > Happy new year! > > We had a brief discussion in our GFSG meeting yesterday also and > I’ve sent a mail to Lisa and their colleagues asking for updates. > > I’ve got no response yet but I’ll inform you once I have more information. > > Best regards > > Wolfgang > > -- > Dr. Wolfgang Ziegler > z-rands > > Im tiefen Bruch 23, D-53773 Hennef, Germany > > Tel: +49 2242 80371 <tel:+49%202242%2080371>; Mobil: +49 151 50445303 > <tel:+49%20151%2050445303> > > StandICT - Supporting European Experts Presence in International Standardisation > Activities in ICT > www.standict.eu <http://www.standict.eu/>, www.linkedin.com/in/standict > <http://www.linkedin.com/in/standict>, > twitter: @Stand_ICT > >> Am 09.01.2024 um 22:13 schrieb Mike Beckerle <mbeckerle(a)apache.org>: >> >> >> Happy new year! >> >> Any news from the ISO/JTC1 folks? Any status we can get? >> >> Thanks >> >> Mike Beckerle >> Apache Daffodil PMC |daffodil.apache.org <http://daffodil.apache.org/> >> OGFDFDLWorkgroup Co-Chair | www.ogf.org/ogf/doku.php/standards/dfdl/dfdl >> <http://www.ogf.org/ogf/doku.php/standards/dfdl/dfdl> >> Owl Cyber Defense | www.owlcyberdefense.com < http://www.owlcyberdefense.com/> >> >> -- Dr. Wolfgang Ziegler z-rands www.z-rands.de Im tiefen Bruch 23, D-53773 Hennef, Germany Tel: +49 2242 80371; Mobil: +49 151 50445303 StandICT - Supporting European Experts Presence in International Standardisation Activities in ICT www.standict.eu, www.linkedin.com/in/standict, twitter: @Stand_ICT

1 0

ICU and dfdl:textNumberPattern issue
by Mike Beckerle 15 Jan '24

15 Jan '24

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

2 2

Confirming DFDL Workgroup call today (2024-01-11)
by Mike Beckerle 11 Jan '24

11 Jan '24

Hope to see you there. I will, hopefully, send out agenda in advance.

1 1

spec bug: Figure 4
by Mike Beckerle 11 Jan '24

11 Jan '24

Section 13.6.1.1, Figure 4: dfdl:textNumberPattern BNF Syntax has a line: vinteger := ('#'* '0'* 'V' '0'* '0') | (integer 'V') prefix := '\u0000'..'\uFFFD' - specialCharacters This is missing a line ending before "prefix", which is a separate production of this BNF grammar. 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

clarification - argument expression to fn:count() function
by Mike Beckerle 11 Jan '24

11 Jan '24

The description of fn:count in section 18.5.2.5 says fn:count() can be called on a node-sequence. It does not seem to require an array/optional path. This seems to be suggesting that if you have say.... <element name="b" type="xs:int"/> <element name="a" type="xs:int"/> <element name="b" type="xs:int" minOccurs="0"/> That one could write fn:count(b) and it should return 1 or 2. The Daffodil project calls this a "query-style" expression, as opposed to just a basic path expression. Furthermore, in the first paragraph of section 18.5.2.5 it says "(Note that DFDL v1.0 does not support sequences of length > 1 as the final results of expressions.)" which suggests that some expressions can constructively return node sequences of length > 1 as intermediate results. Presumably fn:count(b) above is such a situation, as the expression 'b' returns 2 nodes. The above all suggests to me that fn:count(a) would be legal where 'a' is a scalar. This is just always 1 of course. But Section 35 says: Expression value is not single node § Most DFDL expression contexts require an expression to identify a single node, not an array (aka sequence of nodes). There are a few exceptions such as the fn:count(…) function, where the path expression must be to an array or optional element. o Expression value is not array element or optional element. § Some DFDL expression contexts require an array or an optional element. § Example: The fn:count(...) function argument must be to an array or optional element. It is a Schema Definition Error if the argument expression is otherwise. Experience at the Daffodil project is that allowing fn:count argument expression to be a non-array non-optional element, where fn:count would always return 1, just hides errors that are very hard to find, and this situation comes up often as a schema is written. Usually the expression to fn:count is initially correct with an array/optional as the argument, but element nesting evolves, and the paths need updating, but end up referring not to the array/optional element, but that name is now of a scalar enclosing element of the array, so the fn:count is always 1, and the schema is incorrect because the expression is not doing what is intended, but no error is detected. This is then quite hard to isolate and fix. A concrete example of this experience is you start with a schema like: <element name="record" maxOccurs="unbounded"> <complexType> <sequence> .... elements of the record But then you need the valueLength of the whole array of all the records, to store the length for unparsing, so you revise this to: <element name="record"> <complexType> <sequence> <element name="item" maxOccurs="unbounded"/> <complexType> <sequence> .... elements of each record 'item'. And now, paths you had like fn:count(foo/bar/record) are no longer to an array, they are to a scalar, so always return 1. This is decidedly unhelpful in a large schema. It is far better if fn:count(foo/bar/record) becomes an SDE because record is now scalar. So the clarification I'm seeking is whether section 35 was just missed when updates were made about this node-sequence stuff, or if it is reasonable to implement the restrictions in Section 35. I am biased. I want the restrictions in Section 35, but this was muddy enough that I thought we should get a clarification first. Daffodil already doesn't implement any query-style expressions so the fn:count(b) example above would be an SDE in Daffodil. 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 1

Future feature? allow pattern facet on numbers when textNumberRep="standard" and representation="text"
by Mike Beckerle 20 Dec '23

20 Dec '23

It has come up often now that DFDL cannot be strict enough about text number formats because our ICU-based textNumberPattern isn't strict enough or expressive enough of subtle syntax variations. I suggest this could be fixed by just allowing the XSD pattern facet to be used on numeric types when they are known textual and standard (not zoned). For example dfdl:textNumberPattern="00.####" will allow the number "99." to be accepted. There's currently no way to say "when it's an integer, there cannot be a decimal point". People are resistant to the notion that this requires a complex type with a bunch of different elements with different textNumberFormats so that you have an '<int>99</int>' or <dec>99.9</dec> element. They really don't want there to be different paths to this value in the infoset just because of this format issue about the decimal point. It's a painful loss of polymorphism in these path expressions. Instead of a simple path expression to obtain such a value you end up with if (fn:exists(path/int)) then path/int else path/dec Note that DFDL's expression language has no let statement, so in the above if "path" is actually "a/b/c/d/e/f/g" i.e., a typical deep path (which commonly have much longer path steps than my single-letters), then that path is going to be repeated 3 times in the expression. This is pretty unpleasant. Rather than come up with a bunch of ICU mods to tighten up all the places it is lax, and to add features for suppressed decimal points, etc. we could just allow the pattern facet on textual numbers. Then the pattern facet could be "\d\d|\d\d\.\d{1,4}" which would achieve the goal of enforcing the precise pattern desired if you validate after parsing and before unparsing. It would not prevent conversion of the text to the corresponding numeric type, but it would allow an additional tighter check on what the text was. Regular XML Schema allows the pattern facet on all the numeric types, so we would be eliminating what is currently a DFDL restriction, on condition of only when the numeric types have standard text representation. Thoughts? 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 5

Canceled event with note: DFDL Workgroup - DFDL Spec Issues and Actions @ Thu Dec 14, 2023 11am - 12pm (EST) (dfdl-wg@ogf.org)
by Mike Beckerle 14 Dec '23

14 Dec '23

This event has been canceled with a note: "No topics for agenda have been submitted and no email discussion has indicated a need to meet, so today's meeting is cancelled. " DFDL Workgroup - DFDL Spec Issues and Actions Thursday Dec 14, 2023 ⋅ 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 ~~//~~ 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

Reminder - Call for agenda topics for next DFDL WG call on 2023-12-14 T 16:00:00 Z
by Mike Beckerle 07 Dec '23

07 Dec '23

The next call is scheduled for Thursday Dec 14, at 11am US.ET (UTC-5) Please let me know, or discuss on this email list, any agenda topics for discussion. Our hope is that we hear back from ISO JTC1 before this about our PAS application, but if not, and there are no agenda topics, then I will cancel the call . 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