[DFDL-WG] clarification: on suppressed ZL string/hexBinary - do we keep variable assignments?

[Mike Beckerle]

To follow up then,

I have assumed that dfdl:emptyValueDelimiterPolicy isn't even examined
unless the element has default="..." i.e., a non-zero-length default value
specified. I.e., without a default value, there is no concept of emptiness
as distinct from "normal" representation.

Are you suggesting that it is also used to control when an empty string (or
empty hexbinary) is accepted as a normal representation value for an
optional element, vs. treated as a missing value? That's a reasonable
interpretation that I would support, but I don't know that the spec says
that anywhere, so we need to add a sentence. (Unless I'm missing where this
is stated.)

I have also thought that dfdl:emptyValueDelimiterPolicy must be combined
with dfdl:initiator and dfdl:terminator. If the combination of these is
such that the empty representation is zero-length, that is what creates the
situation of interest here, where it is ambiguous whether the value is the
official empty representation or is the normal representation that just so
happens to be of zero length.  That is, there's no special significance to
the 'none' EVDP property value.

For example, if dfdl:emptyValueDelimiterPolicy is 'both', but
dfdl:initiator="" and dfdl:terminator="", then that's just as good as
dfdl:emptyValueDelimiterPolicy='none' in terms of whatever effect this has
on a decision about normal vs. missing.

Does this match your understanding?



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>


On Wed, Aug 1, 2018 at 9:26 AM, Steve Hanson <smh at uk.ibm.com> wrote:

> Whether to add a zero-length string or hexBinary to the infoset for an
> optional element depends on the setting of emptyValueDelimiterPolicy. A
> setting of 'none' stops it from being added.
>
> Regardless, it does not give a processing error, so is therefore
> known-to-exist, and therefore does not cause backtracking, so preserving
> discriminators and variables.
>
> Regards
>
> Steve Hanson
>
> IBM Hybrid Integration, Hursley, UK
> Architect, *IBM DFDL*
> <http://www.ibm.com/developerworks/library/se-dfdl/index.html>
> Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/>
> *smh at uk.ibm.com* <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 at ogf.org
> Date:        24/07/2018 15:15
> Subject:        [DFDL-WG] clarification: on suppressed ZL
> string/hexBinary - do we keep variable assignments?
> Sent by:        "dfdl-wg" <dfdl-wg-bounces at ogf.org>
> ------------------------------
>
>
>
>
> In some situations we parse and get a successful zero-length parse for a
> string or hexBinary.
>
> But because the occurrence is optional, we do NOT add an element to the
> infoset.
>
> In that case, what happens to side-effects that occurred during the
> successful parse. There are two possible kinds of side-effects. Variables
> can be set, and a discriminator can be set to true.
>
> It seems to me that if a discriminator is set, then that *must* be
> preserved, and in that case it would seem the variable settings should be
> retained as well.
>
> Comments?
>
> Mike Beckerle | OGF DFDL Workgroup Co-Chair | Tresys Technology |
> *www.tresys.com* <http://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>
> --
>  dfdl-wg mailing list
>  dfdl-wg at 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20180801/bd797cbf/attachment.html>