[DFDL-WG] Unparsing and choices - (related - Re: Fw: Action 233 (deferred) - "byte order not sufficient..." - draft document on experience with binary format MIL-STD-2045

Mike Beckerle mbeckerle.dfdl at gmail.com
Mon Jul 14 16:31:35 EDT 2014


We'll I am a bit concerned if we cannot generally implement an asymetric
parser and unparser inside the same schema.

That is, if you have calculated element named C, then I think one should be
able to have hidden element A which is used only when parsing (C computed
from A), and hidden element B which is used only when unparsing, (B
computed from C), where B is non-existing on parse, and A is non-existing
on unparse.

I think this trick may work:

<!-- hidden. Found when parsing, not in infoset when unparsing -->
<element name="A" type="xs:string" minOccurs="0"
dfdl:occursCountKind=...whatever.. />

<!-- boolean. Tells whether we're parsing or unparsing based on whether A
is in infoset -->
<dfdl:newVariableInstance ref="areParsing" value ="{
    fn:exists(../A)
  }"/>

<!-- hidden. Length 0 when parsing. Unparsing gets length and value from C
-->
<element name="B" type="xs:string"
    dfdl:lengthKind="explicit"
    dfdl:length="{ if ($areParsing) then 0 else fn:string-length(../C) }"
    dfdl:outputValueCalc="{ ../C }" />

<!-- not hidden -->
<element name="C" type="xs:string" dfdl:inputValueCalc="{ ../A }" />






On Mon, Jul 14, 2014 at 3:23 PM, Steve Hanson <smh at uk.ibm.com> wrote:

> The proposal for action 261 is that the dfdl:length expression is
> evaluated, so that will stop what you propose from working.
>
> For the MIL-STD-2045 'fixedOrTerminated' case then the sequence suggestion
> in the other email is much simpler.
>
> Regards
>
> Steve Hanson
> Architect, *IBM DFDL*
> <http://www.ibm.com/developerworks/library/se-dfdl/index.html>
> Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/>
> IBM SWG, Hursley, UK
> *smh at uk.ibm.com* <smh at uk.ibm.com>
> tel:+44-1962-815848
>
>
>
> From:        Mike Beckerle <mbeckerle.dfdl at gmail.com>
> To:        Steve Hanson/UK/IBM at IBMGB,
> Cc:        "dfdl-wg at ogf.org" <dfdl-wg at ogf.org>
> Date:        14/07/2014 19:51
> Subject:        Re: Unparsing and choices - (related - Re: [DFDL-WG] Fw:
> Action 233 (deferred) - "byte order not sufficient..." - draft document on
> experience with binary format MIL-STD-2045
> ------------------------------
>
>
>
> There has to be a way to get zero-length on parsing, but an
> outputValueCalc string on unparsing.
>
> <defineVariable name="dummyLength" defaultValue="0" external='true'/>
>
> <element name="outputRaw" type="xs:string"
>     dfdl:lengthKind="explicit" dfdl:length="{ $tns:dummyLength }"
>     dfdl:outputValueCalc="{.....}" />
>
> Would this work? The length expression isn't used when unparsing I believe
> in that some other elements are supposed to be storing the length
> information. That's the case here though the length value information isn't
> being stored, what is being stored is a way to determine the length.
>
> Maybe there's something simpler?
>
>
>
> On Mon, Jul 14, 2014 at 1:42 PM, Steve Hanson <*smh at uk.ibm.com*
> <smh at uk.ibm.com>> wrote:
> Mike
>
> Section 17 of the spec says "It is a schema definition error if
> dfdl:inputValueCalc and dfdl:outputValueCalc are specified on the same
> element. "  So outputRaw will give an SDE.
>
> Regards
>
> Steve Hanson
> Architect, *IBM DFDL*
> <http://www.ibm.com/developerworks/library/se-dfdl/index.html>
> Co-Chair, *OGF DFDL Working Group* <http://www.ogf.org/dfdl/>
> IBM SWG, Hursley, UK
> *smh at uk.ibm.com* <smh at uk.ibm.com>
> tel:*+44-1962-815848* <%2B44-1962-815848>
>
>
>
> From:        Mike Beckerle <*mbeckerle.dfdl at gmail.com*
> <mbeckerle.dfdl at gmail.com>>
> To:        Steve Hanson/UK/IBM at IBMGB,
> Cc:        "*dfdl-wg at ogf.org* <dfdl-wg at ogf.org>" <*dfdl-wg at ogf.org*
> <dfdl-wg at ogf.org>>
> Date:        14/07/2014 16:43
> Subject:        Unparsing and choices - (related - Re: [DFDL-WG] Fw:
> Action 233 (deferred) - "byte order not sufficient..." - draft document on
> experience with binary format MIL-STD-2045
>  ------------------------------
>
>
>
> Breaking out this one issue for a separate discussion thread.
>
> Consider the choice below. There is a choice of two different elements
> named raw1 and raw2, then a value element which is computed based on one or
> the other of the alternatives.
>
> <choice>
>        <!-- length kind pattern is needed to bound length to max of 99 -->
>        <element name="raw1" type="xs:string"
>            dfdl:lengthKind='pattern'
>            dfdl:lengthPattern="[^\x7F]{0,99}"
>            dfdl:terminator="%DEL;"/>
>        <element name="raw2" type="xs:string"
>             dfdl:lengthKind="explicit"
>             dfdl:length="100"/>
> </choice>
> <element name='value' type='xs:string'
>      dfdl:inputValueCalc='{ if (fn:exists( ../raw1 ) then ../raw1 else
> ../raw2 }'/>
>
> Now, given the statement below:
>
> SMH: There is no way to make a choice branch fail when unparsing. (The
> only 'backtracking' when unparsing a choice is when the infoset contains no
> branch at all then the spec states that each branch is examined in turn
> until one is found that successfully applies defaults. But that's not
> really backtracking, as you can statically deduce the branch from the
> schema alone, so the 'default' branch to use can be computed up front).
>
> So is there any way to fix this and make the above choice work?
>
> This is the only thing I can think of, which ends up with entirely
> separate elements for parsing and unparsing.
>
> I am not sure this works or should work.
>
> <group name="hidG1">
> <sequence>
> <!--
>    raw1 won't exist on unparsing
>   -->
> <element name="raw1" type="xs:string"
>            dfdl:lengthKind='pattern'
>            dfdl:lengthPattern="[^\x7F]{0,99}"
>            dfdl:terminator="%DEL;"
>            minOccurs='0' dfdl:occursCountKind='implicit'/>
> <!--
>    raw2 will only occur parsing if raw1 doesn't
>    and doesn't exist on unparsing
>    -->
> <element name="raw2" type="xs:string"
>             dfdl:lengthKind="explicit"
>             dfdl:length="100"
>             minOccurs='0' dfdl:occursCountKind='expression'
>             dfdl:occursCount="{ if (fn:exists(../raw1) then 0 else 1 }"/>
> <!--
>    the outputRaw will only be used when unparsing.
>    On parsing it will just get "" as value, and nobody uses the value.
>   -->
> <element name="outputRaw" type="xs:string"
>        dfdl:lengthKind="explicit" dfdl:length="{ 0 }"
>        dfdl:outputValueCalc="{ if (fn:string-length(../value) eq 100 then
> ../value else fn:concat(../value, '&#x7F;') }" />
> <sequence>
> </group>
>
> <!--
>     to use, we hide the cruft in a hidden group
>    -->
> <sequence dfdl:hiddenGroupRef="tns:hidG1"/>
> <element name='value' type='xs:string'
>      dfdl:inputValueCalc='{ if (fn:exists( ../raw1 ) then ../raw1 else
> ../raw2 }'/>
>
>
>
>
>
>
>
> 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
>
>
> 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/20140714/cd386cc8/attachment.html>


More information about the dfdl-wg mailing list