- dfdl-wg - lists.ogf.org

Re: [DFDL-WG] DFDL inputValueCalc restrictions
by Michele Zundo 25 Sep '19

25 Sep '19

I’m also not seeing coming from in dfdl-wg... > On 25 Sep 2019, at 16:25 , Beckerle, Mike <mbeckerle(a)tresys.com> wrote: > > ((( > Strangely, this thread not showing up on dfdl-wg(a)ogf.org. > but is coming to me direct at my tresys email because I am directly addressed also. > > Bradd are you getting bounce-back from the OGF mail system? > > I'll respond here, but I'd prefer that this happen on the ogf dfdl-wg(a)ogf.org email list. > ))) > > > Daffodil project has been building up an experience document about inputValueCalc, outputValueCalc, and hidden groups. The draft is on our wiki here: > > https://s.apache.org/daffodil-experience-with-computed-elements <https://s.apache.org/daffodil-experience-with-computed-elements> > > This will get finalized into an OGF Experience document and a number of changes/corrections to the DFDL spec will come out of it I expect. > > We already have identified that disallowing IVC and OVC on the same element is unnecessary and sometimes you want this. Your case with default values sounds similar. > > We can incorporate your contribution to the experience document. Take a look and see if the existing discussion can just be enhanced with a sentence about also allowing default on an IVC element. If so I can edit and add it there. > From: Bradd Kadlecik <braddk(a)us.ibm.com> > Sent: Wednesday, September 25, 2019 9:48 AM > To: dfdl-wg(a)ogf.org <dfdl-wg(a)ogf.org> > Cc: Steve Hanson <smh(a)uk.ibm.com>; Beckerle, Mike <mbeckerle(a)tresys.com>; Michele Zundo <michele.zundo(a)esa.int>; Liam O'Neill <WILONEIL(a)uk.ibm.com>; DFDL Schemas for Commercial and Scientific Data Formats <smhdfdl(a)gmail.com> > Subject: DFDL inputValueCalc restrictions > > Hello, > > I have one item I'd like to discuss at some point regarding inputValueCalc and not allowing the default property to be specified. I have a use case where the default property would be useful for unparse. It makes perfect sense to not allow it for outputValueCalc however. > > The use case is in forming a connection between an inputValueCalc element and an outputValueCalc element where the incoming document might not contain the inputValueCalc element for unparse and a default value would be desired for the outputValueCalc use. This is an item our customers using DFDL would like to make use of but don't want to require the element to always exist for unparse. > > Regards, > > Bradd Kadlecik > z/TPF Development > Phone: 1-845-433-1573 > E-mail: braddk(a)us.ibm.com <mailto:braddk@us.ibm.com> > 2455 South Rd > Poughkeepsie, NY 12601-5400 > United States > >

1 0

Cancelled: OGF DFDL Working Group call
by Steve Hanson 25 Sep '19

25 Sep '19

1 0

clarifications needed for %ES; and %WSP*; entities
by Mike Beckerle 18 Sep '19

18 Sep '19

Currently, we have gaps in the spec. E.g., in discussion of dfdl:initiator, the spec says %ES; cannot appear alone in the list, but there is nothing prohibiting one from just using dfdl:initiator="%ES;%ES;" or dfdl:initiator="%ES: %ES;" to trivially work around this constraint, even though both of these definitions are nonsense. To avoid repeated discussion of this topic for each of initiator, terminator, and separator, these statements need to be made where ES and WSP* are defined, or in some other central location that discusses DFDL String Literals and whitespace separated lists thereof. %ES; can never appear as part of any other token. I.e., "%ES;A" is the same as just "A" regardless of what "A" is. So %ES; can only appear as a solitary token in a whitespace separated list of delimiter tokens or nilValue tokens. Furthermore, %ES; cannot be repeated in the list, since "%ES; %ES;" means the same thing as just "%ES;". %WSP*; similarly cannot be repeated in the list meaningfully, so that should be prohibited as well. (In fact repeating any token multiple times in the list can be prohibited.) %WSP*; cannot be combined with %WSP+;, as the combination is equivalent to just %WSP+; by itself. Furthermore %WSP*;%WSP*; means the same as %WSP*; alone, so that should also be prohibited. If we add these clarifications, then statements about how %ES; and %WSP*; and their specific constraints for dfdl:initiator and dfdl:terminator and dfdl:separator need not repeat these statements, and the constraints they express do not have obvious gaps. 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

pointers and offsets - BDDL
by Mike Beckerle 30 Aug '19

30 Aug '19

This is a link to a format description language (proprietary) which mentions a pointers/offsets capability. http://www.binarydom.com/sdk/doc/bddl.shtml We may want to review this w.r.t. DFDL capabilities being considered in this area. There aren't too many of these to draw from in standardization. I am trying to get the Tresys one (which is not part of Daffodil) into form where we can describe it here also. 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>

1 0

Action 313: Plus '+' sign and lax textNumberCheckPolicy
by Mike Beckerle 30 Aug '19

30 Aug '19

Looks like ICU changed behavior.... From: Steve Lawrence <slawrence(a)apache.org> Sent: Thursday, August 29, 2019 1:30 PM To: users(a)daffodil.apache.org Subject: Re: Plus '+' sign and lax textNumberCheckPolicy - was: Re: How to model a fixed-length integer that may be padded with space on the left? I think this is a difference in ICU version? A little grepping through ICU source, I found a change [1] to their number parsing logic in Dec 2017: + if (!isStrict) { + parser.addMatcher(WhitespaceMatcher.getInstance()); + parser.addMatcher(new PlusSignMatcher()); + } That looks to me like a change to make it so plus signs are always matched in lax/lenient mode regardless of the pattern (Daffodils current behavior). A couple minor changes have been made to that section, but nothing that allows you to turn if off if lenient is on. It's hard to tell in the git history what release that was in, but it looks like around version 61, which is relatively new (Daffodil is on version 62). Also, the latest version of DecimalFormatProperties.java (looks to be an internal implementation, so no online javadocs), has javadocs that states that plus signs are always allowed in lenient/lax mode [2]. I think this is a change in ICU behavior in newer versions. - Steve [1] https://github.com/unicode-org/icu/commit/68340c8464bd988477d6c88f46f9dfe45… [2] https://github.com/unicode-org/icu/blob/master/icu4j/main/classes/core/src/…

2 1

Cancelled: OGF DFDL Working Group call
by Steve Hanson 29 Aug '19

29 Aug '19

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

Latest OGF DFDL WG Call Minutes
by Steve Hanson 29 Aug '19

29 Aug '19

Please find minutes from the latest call at https://redmine.ogf.org/projects/dfdl-wg/news Next call is 4 weeks time - Sept 26th. 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 Working Group call
by Steve Hanson 29 Aug '19

29 Aug '19

1 0

clarification needed: textNumberCheckPolicy lax includes lax-ness about plus signs.
by Mike Beckerle 29 Aug '19

29 Aug '19

Excerpt from daffodil users mailing list indicates that the discussion of how "lax" textNumberCheckPolicy="lax" is w.r.t. plus signs on numbers. ------------------------------ > If you set textNumberCheckPolicy="lax", then > we do ignore leading plus signs in the data The DFDL specification doesn't seem to say that a leading plus sign is ignored. Here's what it says: If 'lax' and dfdl:textNumberRep is 'standard' then grouping separators are ignored, leading and trailing whitespace is ignored, leading zeros are ignored and quoted characters may be omitted. Nothing about ignoring plus signs in that. 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

Agenda for OGF DFDL WG Call
by Steve Hanson 29 Aug '19

29 Aug '19

Please find agenda for today's call on Redmine at https://redmine.ogf.org/dmsf_files/13593?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