[DFDL-WG] Proposal: Adopt experimental emptyElementParsePolicy property in DFDL v1.0
Steve Hanson
smh at uk.ibm.com
Wed Nov 27 11:35:31 EST 2019
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>
More information about the dfdl-wg
mailing list