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 <mbeckerle.dfdl@gmail.com>
To:
DFDL-WG <dfdl-wg@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@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@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