September 2016 - dfdl-wg

OGF DFDL WG Call Agenda 2016-09-16
by Steve Hanson 13 Sep '16

13 Sep '16

Please find agenda for call on Redmine at https://redmine.ogf.org/dmsf_files/13541?download= Regards Steve Hanson IBM Integration Bus, Hursley, UK Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh(a)uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890

1 0

Suggest should be optional feature of DFDL - dfdl:utf16Width='variable' and other corner cases
by Mike Beckerle 13 Sep '16

13 Sep '16

Given the limited set of required encodings for a conforming DFDL processor, I believe dfdl:utf16Width='variable' should be an optional feature. That's just consistency with what is optional already. But it is also quite hard to implement. There are other situations that are very hard to implement, probably never used by real users, yet which are non optional in the spec: I would suggest that dfdl:lengthKind='explicit' for elements of complex type, with dfdl:lengthUnits='characters' and a variable-width encoding like utf-8 is very problematic to implement. I am pretty sure IBM DFDL has no implementation of this per email threads, and I know I don't want to implement this in Daffodil even though we're trying to be very comprehensive in the implementation eventually. I think implementations should be free to just not implement this. These sorts of cases often exist just because we're trying to preserve some orthogonality of composition in the language. So it's possible to do quite a few things that probably aren't ever needed by anyone, that reflect ill-defined data formats, etc. I'd rather not document a bunch of "non-conformances" for Daffodil or other implementations for these sorts of things. I'd like to say we don't implement them, but they're optional, and so that's allowed. Comments? 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

clarification needed: setVariable - executes before or after framing of the element/model group
by Mike Beckerle 07 Sep '16

07 Sep '16

The spec defines where setVariable executes as a statement relative to element processing and model-group processing. Question is: what does element and model group processing mean: the value region of the element, the content region of the element, or the whole element including all framing? So, for an element, spec says that setVariables run after the element. Rhetorical question: Does "after" mean after the terminator (including any expression for the terminator) has completed? Yes, because otherwise a element could contain the value of its own terminator, and that wouldn't work for lengthKind='delimited' as you would need the value to get the terminator to parse the value. So 'after' has to mean after the terminator, meaning all framing, and any other expression that can affect the length or interpretation in forming the element. For a model group, the spec says that setVariables run before the model group. So, can a sequence carry a set-variable that sets a variable value that is then used in the initiator property of that very sequence? E.g., <xs:sequence dfdl:initiator="{ $init }"> <xs:annotation><xs:appinfo ...> <dfdl:setVariable ref="init">{ ../someplace/else }</dfdl:setVariable> </xs:appinfo></xs:annotation> ..... reset of sequence </xs:sequence> If this is not allowed for the initiator, what about for the terminator or separator, or outputNewLine or encoding or any other property that affects the syntax of the model group? What about discriminators/asserts. Do those run before the sequence's initiator is matched, or after? E.g., can a discriminator indicate "true", but then the initiator fails to match? When unparsing, you don't execute discriminator/assert at all, so no guidance there. Maybe this is clear already, but I am not sure if setVariables should run before any framing of a model group, or after the framing, but before the content region, or before the value region. ...mikeb 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 3