[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

[Steve Hanson]

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
Co-Chair, OGF DFDL Working Group
IBM SWG, Hursley, UK
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 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:inputValueCalc='{ "" }'
       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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/dfdl-wg/attachments/20140714/42c1a9ca/attachment-0001.html>