[DFDL-WG] Proposal: Adopt experimental emptyElementParsePolicy property in DFDL v1.0

[Steve Hanson]

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 at uk.ibm.com
tel:+44-1962-815848
mob:+44-7717-378890
Note: I work Tuesday to Friday 



From:   Mike Beckerle <mbeckerle.dfdl at gmail.com>
To:     DFDL-WG <dfdl-wg at ogf.org>
Date:   16/10/2019 20:15
Subject:        [EXTERNAL] [DFDL-WG] Proposal: Adopt experimental 
emptyElementParsePolicy property in DFDL v1.0
Sent by:        "dfdl-wg" <dfdl-wg-bounces at ogf.org>




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 at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20191127/685b3051/attachment-0001.html>