- dfdl-wg - lists.ogf.org

Latest OGF DFDL WG Call Minutes
by Steve Hanson 07 Jan '21

07 Jan '21

Please find minutes from the latest call at https://github.com/OpenGridForum/DFDL/wiki/DFDL-Workgroup-News 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

1 0

Agenda for OGF DFDL WG Call
by Steve Hanson 07 Jan '21

07 Jan '21

Please find agenda for next call on GitHub at https://github.com/OpenGridForum/DFDL/blob/master/calls/2021-01-07_DFDL-WG-… (Note - from now on all call agendas and minutes will be in the GitHub DFDL repo) 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

1 0

agenda item - review public comments
by Mike Beckerle 07 Jan '21

07 Jan '21

The public comment period is over. I'd like to go through the public comments, which should capture all the outstanding issues for the DFDL v1.0 spec., and narrow down on any where we still don't have a good resolution. My hope would be to edit the spec and review the edits exactly once, and have a final draft this month. To do that we need draft language for resolving the outstanding issues. Public comments are here: - https://github.com/OpenGridForum/Editor/issues Several are supportive comments, but do not suggest changes specifically. I plan to just leave those open until the final GFD comes out. The others that require some actual change and that I would close once addressed in the spec are: - https://github.com/OpenGridForum/Editor/issues/16 - large block of grammar/wording corrections. There is some ongoing commentary on this ticket to get clarity on some of the points of this detailed public comment. Most of the suggested changes are not controversial and can just be applied as suggested. - https://github.com/OpenGridForum/Editor/issues/15 - just needs specific wording to be drafted. - https://github.com/OpenGridForum/Editor/issues/14 - we need to decide: optional, or implementation-dependent/defined - plus specific wording needed - https://github.com/OpenGridForum/Editor/issues/9 - ready to edit into the spec. - https://github.com/OpenGridForum/Editor/issues/8 - just needs specific wording to be drafted --mikeb Mike Beckerle | OGF DFDL Workgroup Co-Chair | Owl Cyber Defense | www.owlcyberdefense.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

cutover to github - also need to capture mailing list history
by Mike Beckerle 28 Dec '20

28 Dec '20

Another thing we need to capture. Our dfdl-wg mailing list is archived, and we don't want to lose those archives. So I assume we need to capture those and somehow migrate those to github or some other permanent vehicle for posterity as well. Mike Beckerle | OGF DFDL Workgroup Co-Chair | Owl Cyber Defense | www.owlcyberdefense.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

Action 315: fn:count(.), fn:exists(.)
by Mike Beckerle 10 Dec '20

10 Dec '20

There are 4 functions which operate on the infoset and it is unclear their behavior depending on when they are evaluated during parse/unparse. The 4 functions are fn:count, fn:exists, fn:exactly-one, and fn:empty. The behavior when unparsing is less problematic, because one could simply require the infoset nodes being referenced to be fully-constructed before these functions are allowed to evaluate. However, when parsing the behavior is more subtle, and unparsing may want to be made consistent with decisions about behavior for parsing. Our call minutes about this action item suggest reviewing the known-to-exist and known-not-to-exist definitions to see whether these function definitions should be defined in terms of that. I have reviewed those sections, and so far I'm not sure they will contribute. The general problem is this, in terms of fn:count(path). The path is to an infoset node or an array of occurrences that is currently being parsed. It is possible that the status of known-to-exist or not is simply not well known at the point the expression is being evaluated. The answer to fn:count(path) wants to always be the same as if the infoset were fully constructed at the time the expression is evaluated. As evaluation may occur during parsing, it is just not defined if the evaluation of the expression itself determines whether the item itself is known to exist or not. Ex: <xs:element name="outerArray" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="innerArray" maxOccurs="unbounded"> <xs:complexType> <xs:sequence> <xs:element name="count" type="xs:int" dfdl:inputValueCalc='{ fn:count(../..) }'/> .... </xs:sequence> </x:complexType> </xs:element> </xs:sequence> </xs:complexTYpe> </xs:element> In the above, we see that fn:count has as argument a relative path to the array element named "outerArray". There are a few observations here. 1) If we define fn:count in this case to actually have anything to do with the current number of array elements in outerArray, then we will have tightly constrained implementations to a very sequential notion of parsing. The notion of "current" state of the array implies an algorithm where the number of current occurrences is changing. E.g., we would preclude an implementation that knows the length of all outerArray elements from parsing all the children simultaneously in parallel, or at minimum make this quite hard to achieve because each parallel computation would have to somehow simulate the right "current number" of occurrences. 2) The question arises of fn:count(../..) vs. fn:count(../../../outerArray), vs. fn:count(../../../outerArray[i]) where i is the index of the enclosing parent outerArray instance that contains this calculation. Arguably, fn:count(../..) could be considered equivalent to fn:count(../../../outerArray[i]), both of which seem like they should always return '1' since the count of number of instances of a single index point, single node, is 1. 3) Arguably, fn:count(path) could be illegal whenever the path is to an enclosing element. We could simply define this usage to be illegal. I cannot come up with any reason to actually need this functionality. When parsing we could require the path argument to be to pre-existing part of the infoset, and when unparsing it would have to be to either pre-existing or later parts of the infoset, but specifically not the current infoset elements. If we make this an SDE, then this would seem to be the conservative design point which preserves our ability to assign a future meaning to this usage, should a need arise. My recommendation: Expressions evaluated as part of an element parsing or unparsing cannot refer to the count or existence of the current element occurrence being parsed, nor any enclosing element occurrence, nor any enclosing array element. This would seem to rule out any use of absolute paths in arguments to fn:count, because the root element is not (necessarily) known-to-exist until the entire parse completes successfully. Yet clearly we want to be able to refer to the fn:count of a prior sibling array, and that reference should be able to use either a relative or absolute path. So it's not that the argument path "passes through" a node that may or may not exist, but that it ends on one that the existence or not of which doesn't depend on the existence or not of the current node. I'm a bit uncertain of good language to express this constraint on what the path argument is allowed to refer to, but the notion is one of a sort of circular definition; hence, it's a schema definition error. Mike Beckerle | OGF DFDL Workgroup Co-Chair | Owl Cyber Defense | www.owlcyberdefense.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>

3 3

OGF DFDL Working Group Call
by Steve Hanson 10 Dec '20

10 Dec '20

Calls for 2021. OGF DFDL WG call dial-in details. https://ibm.webex.com/meet/smh OGF DFDL Home: http://www.ogf.org/dfdl GitHub DFDL: https://github.com/OpenGridForum/DFDL DFDL Getting Started: https://community.ibm.com/community/user/middleware/viewdocument/get-starte… DFDL 1.0 Spec: http://www.ogf.org/documents/GFD.207.pdf Daffodil Apache incubator: https://daffodil.apache.org/ IBM DFDL: https://www.ibm.com/support/knowledgecenter/en/SSTTDS_11.0.0/com.ibm.etools…

1 0

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

09 Dec '20

Please find agenda for next call on GitHub at https://github.com/OpenGridForum/DFDL/blob/master/calls/2020-12-10_DFDL-WG-… (Note - from now on all call agendas and minutes will be in the GitHub DFDL repo) 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

1 0

OGF DFDL WG Call 2020-10-26 cancelled
by Steve Hanson 25 Nov '20

25 Nov '20

Thanksgiving in USA 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 25 Nov '20

25 Nov '20

1 0

Trackers all moved to github
by Mike Beckerle 23 Nov '20

23 Nov '20

All open trackers on DFDL v1.0 have been converted to public comments (there were 2) All open trackers on DFDL v2.0 have been converted to issues here: https://github.com/OpenGridForum/DFDL/issues with DFDL 2.0 label. Mike Beckerle | OGF DFDL Workgroup Co-Chair | Owl Cyber Defense | www.owlcyberdefense.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