- dfdl-wg - lists.ogf.org

OGF DFDL WG Call on 2018-05-01 - cancelled
by Steve Hanson 27 Apr '18

27 Apr '18

Apologies but I can't make the call next Tuesday Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

Cancelled: OGF DFDL Working Group Call
by Steve Hanson 27 Apr '18

27 Apr '18

1 0

Latest OGF DFDL WG Call Minutes
by Steve Hanson 18 Apr '18

18 Apr '18

Please find minutes from the latest call at https://redmine.ogf.org/projects/dfdl-wg/news 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

Confirmed: OGF DFDL Working Group Call (17 Apr 15:00 GDT)
by Steve Hanson 17 Apr '18

17 Apr '18

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 next OGF DFDL WG Call
by Steve Hanson 17 Apr '18

17 Apr '18

Please find agenda for call on Redmine at https://redmine.ogf.org/dmsf_files/13575?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] Review/Feedback wanted on proposal: Data Streaming for base64 and other Layered Transformations
by Mike Beckerle 06 Apr '18

06 Apr '18

Never mind that prior one. I've simplified it even further. (The "super simplified" one.) https://cwiki.apache.org/confluence/display/DAFFODIL/Proposal%3A+Data+Layer… 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 Fri, Apr 6, 2018 at 3:14 PM, Mike Beckerle <mbeckerle.dfdl(a)gmail.com> wrote: > On looking into implementation complexity I've come up with > simplifications that don't reduce expressive power at all, but massively > simplify implementation (and documentation, and testing...) burdens for > this proposed feature. > > > https://cwiki.apache.org/confluence/display/DAFFODIL/ > Proposal%3A+Data+Layering+for+base64+-+Simplified > > Feedback is very welcome. > > 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 Thu, Feb 15, 2018 at 10:44 AM, Mike Beckerle <mbeckerle.dfdl(a)gmail.com> > wrote: > >> We have a great deal of demand for the ability to describe data formats >> that include layered transformations - that is, regions within the data >> that need to be algorithmically transformed before parsing and after >> unparsing. >> >> The IETF data formats make extensive use of line folding, base64, etc. >> Many formats allow compressed payloads. All these are examples of >> "layering" where a region of the data stream can be identified, >> algorithmically transformed, and then subsequently further parsed. (The >> inverse process for unparsing obviously.) >> >> Our draft proposal, that we are hoping to implement in Daffodil, is here: >> >> https://cwiki.apache.org/confluence/display/DAFFODIL/Proposa >> l%3A+Data+Streaming+for+Base64+and+other+Layered+Transformations >> >> Any feedback on this is very welcome, and can be addressed to dfdl-wg >> mailing list. >> >> 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

Re: [DFDL-WG] Review/Feedback wanted on proposal: Data Streaming for base64 and other Layered Transformations
by Mike Beckerle 06 Apr '18

06 Apr '18

On looking into implementation complexity I've come up with simplifications that don't reduce expressive power at all, but massively simplify implementation (and documentation, and testing...) burdens for this proposed feature. https://cwiki.apache.org/confluence/display/DAFFODIL/Proposal%3A+Data+Layer… Feedback is very welcome. 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 Thu, Feb 15, 2018 at 10:44 AM, Mike Beckerle <mbeckerle.dfdl(a)gmail.com> wrote: > We have a great deal of demand for the ability to describe data formats > that include layered transformations - that is, regions within the data > that need to be algorithmically transformed before parsing and after > unparsing. > > The IETF data formats make extensive use of line folding, base64, etc. > Many formats allow compressed payloads. All these are examples of > "layering" where a region of the data stream can be identified, > algorithmically transformed, and then subsequently further parsed. (The > inverse process for unparsing obviously.) > > Our draft proposal, that we are hoping to implement in Daffodil, is here: > > https://cwiki.apache.org/confluence/display/DAFFODIL/ > Proposal%3A+Data+Streaming+for+Base64+and+other+Layered+Transformations > > Any feedback on this is very welcome, and can be addressed to dfdl-wg > mailing list. > > 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

OGF DFDL WG Call today 2018-04-03 - cancelled
by Steve Hanson 03 Apr '18

03 Apr '18

Apologies for late notice - a deadline means I can't make the call today Regards Steve Hanson Architect, IBM DFDL Co-Chair, OGF DFDL Working Group Hursley, UK smh(a)uk.ibm.com tel:+44-1962-815848

1 0

Cancelled: OGF DFDL Working Group Call
by Steve Hanson 03 Apr '18

03 Apr '18

1 0

Feature needed: Possible Root element annotation
by Mike Beckerle 30 Mar '18

30 Mar '18

I think IBM DFDL already has this label. I think we need to standardize it as part of DFDL. Seems DFDL schemas, to make compilation feasible, and avoid many unnecessary warnings and spurious weirdness, must have a way of deciding what top level elements are intended to be Root elements. Some global element decls might have clearly upward-and-outward relative path expressions inside them, and such elements are unsuitable for use as root elements. We don't want to issue diagnostics for these unless the user expresses intent to use one of them as a root. In that case they have made a mistake and need a diagnostic. I believe one could sidestep the issue by only creating elements for things that could be roots, and use global types or global groups otherwise. But we have users who really want to use lots of global elements and element refs for their own reasons (they want the schema to have a certain regular structure for non-DFDL reasons) We definitely do see a need for many elements of a schema to be possible roots. This is particularly important for message-oriented formats where there is no natural root element that surrounds all the messages because they are arriving on a non-bounded stream that is effectively open "forever". 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