clarification needed: section 14.2.1 potentially trailing group
Section 14.2.1 introduces the term "potentially trailing group". It is referred to only in the next paragraph which defines "Trailing or Actually Trailing". Presumably this was done because it was intended that separator suppression would consider a potentially trailing group to have some separator suppression behavior. However, all subsequent discussion of separator suppression I find discusses only separators between elements. So we should either drop "potentially trailing group" and its definition, and modify the definition of "Trailing or Actually Trailing" to specify only elements.... or fix everyplace where things are specific to elements to refer to terms (term meaning element or model group). I suggest it is ok to eliminate "potentially trailing group". First, it simplifies things. If you want separator suppression behavior, well it applies only to potentially trailing things, and those things must be elements. Since only elements can be optional (only elements can have min/max occurs in DFDL), this means if you want separator suppression behavior, the separated things must be elements, period. Any model group, regardless of whether it has framing syntax, zero-length, whatever, would be considered required, and elements prior to it within a sequence group could not be considered potentially trailing and so separatorSuppressionPolicy would never result in suppression. I do not think we lose any expressive power in DFDL by requiring separator suppression to work only on elements. It perhaps requires you to put an element decl around something you might not want to. But there are lots of things in DFDL that require use of extra tiers of elements. Daffodil does not implement potentially trailing model groups, or if it does, it's super buggy. DFDL4S is binary only so doesn't have this stuff. What does IBM DFDL do here? Do you allow a sequence like: <sequence> optional element A optional element B <sequence> optional element C </sequence> optional element D </sequence> to have separator suppression that applies to elements A and B, or only to element D ? 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>
Mike I am not comfortable with removal of the concept of a potentially trailing group. It is there to cope with the embedding of a group within a group. A concrete example where this might be useful is a CSV column which could either be a number or a string. It lets the modeller use a local choice in the complex element for the row, with the choice containing a number element and a string element, and for the properties of trailing separator suppression to be honoured. The problem as you say is the subsequent discussion and tables in sections 14.2.2 and 14.2.3 which is all about elements. Maybe the way to cope with the discussion and tables is using our 'source transformation' approach ? Disappear the sequences & choices (recursively) and additionally for a choice disappear all but first element. Regards Steve Hanson IBM Hybrid Integration, Hursley, UK Architect, IBM DFDL Co-Chair, OGF DFDL Working Group smh@uk.ibm.com tel:+44-1962-815848 mob:+44-7717-378890 Note: I work Tuesday to Friday From: Mike Beckerle <mbeckerle.dfdl@gmail.com> To: dfdl-wg@ogf.org Date: 28/03/2018 22:43 Subject: [DFDL-WG] clarification needed: section 14.2.1 potentially trailing group Sent by: "dfdl-wg" <dfdl-wg-bounces@ogf.org> Section 14.2.1 introduces the term "potentially trailing group". It is referred to only in the next paragraph which defines "Trailing or Actually Trailing". Presumably this was done because it was intended that separator suppression would consider a potentially trailing group to have some separator suppression behavior. However, all subsequent discussion of separator suppression I find discusses only separators between elements. So we should either drop "potentially trailing group" and its definition, and modify the definition of "Trailing or Actually Trailing" to specify only elements.... or fix everyplace where things are specific to elements to refer to terms (term meaning element or model group). I suggest it is ok to eliminate "potentially trailing group". First, it simplifies things. If you want separator suppression behavior, well it applies only to potentially trailing things, and those things must be elements. Since only elements can be optional (only elements can have min/max occurs in DFDL), this means if you want separator suppression behavior, the separated things must be elements, period. Any model group, regardless of whether it has framing syntax, zero-length, whatever, would be considered required, and elements prior to it within a sequence group could not be considered potentially trailing and so separatorSuppressionPolicy would never result in suppression. I do not think we lose any expressive power in DFDL by requiring separator suppression to work only on elements. It perhaps requires you to put an element decl around something you might not want to. But there are lots of things in DFDL that require use of extra tiers of elements. Daffodil does not implement potentially trailing model groups, or if it does, it's super buggy. DFDL4S is binary only so doesn't have this stuff. What does IBM DFDL do here? Do you allow a sequence like: <sequence> optional element A optional element B <sequence> optional element C </sequence> optional element D </sequence> to have separator suppression that applies to elements A and B, or only to element D ? 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 -- dfdl-wg mailing list dfdl-wg@ogf.org https://www.ogf.org/mailman/listinfo/dfdl-wg 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
participants (2)
-
Mike Beckerle -
Steve Hanson