- dfdl-wg - lists.ogf.org

Cancelled: OGF DFDL Working Group Call
by Steve Hanson 09 Jan '20

09 Jan '20

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

Cancelled: OGF DFDL Working Group Call
by Steve Hanson 09 Jan '20

09 Jan '20

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 09 Jan '20

09 Jan '20

Please find minutes from the latest call at https://redmine.ogf.org/projects/dfdl-wg/news Next call is 23rd Jan 2020. 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 smh＠uk.ibm.com 09 Jan '20

09 Jan '20

Today's call will be open from 15 minutes past the hour, so a slight delay. Regards Steve Hanson IBM Hybrid Integration, Hursley, UK Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh(a)uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890 Note: I work Tuesday to Friday 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

Confirmed: OGF DFDL Working Group Call (9 Jan 16:00 GMT in https:/ibm.webex.com/meet/smh)
by Steve Hanson 09 Jan '20

09 Jan '20

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

Agenda for OGF DFDL WG Call
by Steve Hanson 09 Jan '20

09 Jan '20

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

Re: [DFDL-WG] Latest comments
by Mike Beckerle 09 Jan '20

09 Jan '20

Martin, thanks for this next installment. Question: previously you sent pages up to 62. Are there no additional markups to those pages, i.e., this is really just additional marked pages, or does this file replace prior those as you added new markings to those? E.g., I have 3 files now. pages 1 -32 marked, pages 32 to 62 marked, and this file, which I am tentatively naming pages-63-123 unless you tell me this subsumes the prior 32 to 62 file. As for additional effort, there is no major hurry, I hope to get started on editing and writing changed sections but honestly I think that may be February before I get to it. So if you keep chipping away at this review as you have time it would be great. 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> On Wed, Jan 8, 2020 at 6:29 PM Martin Westhead <martin(a)westhead.me> wrote: > [image: PDF file] > gwdrp-dfdl-v1.0.5-r11-change-… > > <https://drive.google.com/file/d/1Zr5mV5sJduiSThXmq8Ria6Lpf9B14bfs/view?usp=…> > > Hi Mike, > > Here is the latest version of the comments - I’m up to page 123 (still a > ways to g o I’m afraid). > > I have to say it’s great the see DFDL finished. I’m excited for the small > part I have played in its journey. > > Things definitely improved after page 82. Since it became more clearly > reference and less narrative and the forward references were referring to > things that were closer and at a much more detailed level. > > So I think the real challenge with the doc is pages 20-80 that seem to be > telling a story but use concepts and ideas that have not be > defined/introduced to the reader. Meaning that the doc would need multiple > passes to be comprehensible. My suggestion would be to try to extend the > introductory material to introduce some of the key missing ideas like > Infoset and property and talk a little about how the properties are > arranged on the XML elements. It probably not that much but could make the > doc much more comprehensible. > > The next few weeks I am mostly going to be slammed - I’m racing to deliver > value in my new role and have a lot of ground to cover. But I’m happy to > chip away at the doc as best I can (commenting is faster now post p82). Let > me know if there is a date beyond which it is no longer useful? > > Thanks for pulling me back in - its great to see what you have created... > > Martin >

1 1

Actions 279, 293, 314, 306 - Updated new Errata 5.60-5.63 for review
by Mike Beckerle 03 Jan '20

03 Jan '20

I created 4 new errata in the errata document corresponding to Actions 279, 293, 314, and 306. I skipped the route of creating trackers first - just to reduce the number of steps. The updated errata document for review has been uploaded to redmine here: https://redmine.ogf.org/dmsf_files/13384?download= I also have added numerous formatting related change items to the tracker for minor/typographical changes here: https://redmine.ogf.org/issues/233 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

clarification needed: unparsing and hidden group choices and choices with dfdl:choiceDispatchKey
by Mike Beckerle 13 Dec '19

13 Dec '19

So interesting issue. Comes up as part of our experience implementing the advanced expression language features: hidden groups, and computed elements. We have hidden groups in DFDL. If a xs:choice is inside a hidden group, then by definition, when unparsing, elements corresponding to some branch of the choice are not in the Infoset. DFDL spec clearly states that dfdl:outputValueCalc is not allowed on the head of a choice branch. But elements inside hidden groups must have dfdl:outputValueCalc, or a default value, otherwise there's no way for them to be filled in as part of the augmented infoset. So the only way a choice can be inside a hidden group is if the head of the choice branches have default values. This is not sufficient. I do not think it was our intention to make hidden groups incapable of holding things complex enough to contain a choice. Rather, the point is to be able to hide things that have excess complexity needed only for parsing/unparsing, so that they need not appear in the final Infoset. So if a choice is allowed inside a hidden group, then a mechanism is needed by which when unparsing a choice branch is selected based on values of other parts of the Infoset, and then the elements of that branch are computed and added to the augmented infoset. Note that without hidden groups, this problem never arises, as the Infoset always has to take a position on choice branches by having an unambiguous element in it. There are 3 cases: 1. unparsing an xs:choice where for parsing, each branch has a discriminator, or is resolved by the simple "first successful parse" rule. 2. unparsing an xs:choice with dfdl:choiceDispatchKey 3. unparsing xs:choice with dfdl:initiatedContent='yes' For all cases, I suggest we must remove the restriction on dfdl:outputValueCalc being disallowed on choice branch head. For (1). First branch where the branch can be constructed successfully is added to the augmented infoset. This is a case where an unparse error is non-fatal, and causes a form of unparser backtracking through alternatives. Branches would be attempted in schema order. For (2) I suggest dfdl:unparseChoiceDispatchKey, evaluated at unparse time only. Produces a choice branch key. That choice branch is then constructed, and default values or dfdl:outputValueCalcs are used to fill in values. (BTW: this is the driving use case we have in Daffodil for this issue.) For (3).... I have no specific solution. I think it may not actually be a separate case and has to be treated as (1) or (2). Comments/Discussion?

2 1

preliminary new spec draft with all errata - in HTML - available
by Mike Beckerle 13 Dec '19

13 Dec '19

The current DFDL spec dates from Sept 2014. There have been numerous corrections and clarifications listed in a separate errata document. To assist the DFDL user and implementer community a preliminary version of this revised spec is being made available which has all errata integrated into it. This is far easier to use and has change-tracking so the changes from the Sept 2014 revision are highlighted. You'll find a link to this preliminary version here: https://opengridforum.github.io/DFDL Keep in mind this is a work-in-progress and will change. This homepage link will remain live, but the specific document link you find there will break when new revisions come out. This is hosted at the new OGF github site, and served using github pages. 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