We need to add the new property to Section 22 Property Precedence. I think we need to square away the effects of 'treatAsAbsent' on establishing existence (section 9.3.1). Because absent "behaves as if the element occurrence is 'missing'"(taken from 9.2.4) and missing implies known-not-to-exist, then 'treatAsAbsent' implies known-not-to-exist. Which is correct, and how IBM DFDL behaves. 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 To: DFDL-WG Date: 16/10/2019 20:15 Subject: [EXTERNAL] [DFDL-WG] Proposal: Adopt experimental emptyElementParsePolicy property in DFDL v1.0 Sent by: "dfdl-wg" A feature is described in https://redmine.ogf.org/dmsf_files/13596?download=. It describes a new property to control parser behavior which is already implemented as the standard behavior by IBM DFDL and as an optional experimental behavior by Daffodil. This is desirable functionality and it is needed for some interoperability between these implementations; hence, I propose it be included in the DFDL 1.0 spec., however, aspects that aren't implemented by all implementations of DFDL should be made optional features. We would have to create an erratum for it. I suggest the following are the changes that would be needed. * Section 9.4.2 is amended by inserting a new first paragraph "The property dfdl:emptyElementParsePolicy controls the behavior when empty representation is established while parsing. If dfdl:emptyElementParsePolicy is 'treatAsAbsent', then the empty representation is treated the same as the absent representation, and no default values are considered for addition to the infoset. The remainder of this section describes the behavior for dfdl:emptyElementParsePolicy='treatAsEmpty'." * Section 12.2 - Property description from experimental features document goes right after dfdl:emptyElementDelimiterPolicy. * Section 21 - The row for feature "Defaults" is modified. In the Detection column add "dfdl:emptyElementParsePolicy='treatAsEmpty'". The upshot of this change is that we have the pain in the neck of introducing a new property to implementations, but what we get is that IBM DFDL behavior and Daffodil behavior are then both conforming to the DFDL spec. This is way better than having to document non-conformance or deal with extension features (that not everyone has) to obtain portability. 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://urldefense.proofpoint.com/v2/url?u=https-3A__www.ogf.org_mailman_listinfo_dfdl-2Dwg&d=DwICAg&c=jf_iaSHvJObTbx-siA1ZOg&r=AJa9ThEymJXYnOqu84mJuw&m=YdfWuI_Kiw9EMJnMKIBxApL49OlWc8jLtvF-unpfmPA&s=Id72QwfIdXvAXjqmP3Ee2jBmFEWlsn4pPw6qBzRz4CA&e= 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