No - no changes. I've tried various combinations... no joy. Parse/unparse works - daffodil exit codes w/ zero (0) in both cases:...
+ daffodil parse --validate=on -s samp.dfdl.xsd -r samp.dfdl.xsd -Dheader=absent -o out/_-_home_-_attila_-_CDES_-_trunk_-_ndpp_-_data_-_JITC_-_ndpp_h2l_ascii_-_mu_16_-_ControlData_-_samp.xml /home/attila/CDES/trunk/ndpp/data/JITC/ndpp_h2l_ascii/mu_16/ControlData/samp.txt + parse_exit_code=0 + echo daffodil parse exit code: 0 daffodil parse exit code: 0 + date Tue 19 Apr 2022 11:17:57 AM EDT + daffodil unparse --validate=on -s samp.dfdl.xsd -r samp.dfdl.xsd -Dheader=absent -o out/_-_home_-_attila_-_CDES_-_trunk_-_ndpp_-_data_-_JITC_-_ndpp_h2l_ascii_-_mu_16_-_ControlData_-_samp.txt out/_-_home_-_attila_-_CDES_-_trunk_-_ndpp_-_data_-_JITC_-_ndpp_h2l_ascii_-_mu_16_-_ControlData_-_samp.xml + unparse_exit_code=0 + echo daffodil unparse exit code: 0 daffodil unparse exit code: 0 However, diff between source and unparsed ~.txt files gets error b/c trailing <CR><CR><LF> is not generated on output. On Tue, Apr 19, 2022 at 11:21 AM Steve Lawrence <slawre...@apache.org> wrote: > I tested with 2.4.0. If I remove the CRCRLF separator on line 33 that > you have highlighted then I get an error about no forward progress: > > $ daffodil --version > Apache Daffodil (incubating) 2.4.0 > > $ daffodil parse -Dheader=absent -s samp.dfdl.xsd samp.txt > [error] Parse Error: Choice dispatch branch failed: List(Parse Error: No > forward progress. > Schema context: sequence[1] Location line 33 column 12 in > file:/home/slawrence/downloads/samp/samp.dfdl.xsd > Data location was preceding byte 37) > Schema context: choice[1] Location line 31 column 14 in > file:/home/slawrence/downloads/samp/samp.dfdl.xsd > Data location was preceding byte 37 > [error] Parse Error: No forward progress. > Schema context: sequence[1] Location line 33 column 12 in > file:/home/slawrence/downloads/samp/samp.dfdl.xsd > Data location was preceding byte 37 > > Do you have any other changes to the schema? > > On 4/19/22 11:05 AM, Attila Horvath wrote: > > Keep in mind I'm using Daffodil 2.4.0 > > > > I understand and your explanation makes sense; however... > > > > When I remove highlighted DFDL separator attributes on line #33 per > suggestion:... > > image.png > > I get identical result:... > > image.png > > I.E. <CR><CR><LF> still consumed prior to 'tailing-rec' element > processing. > > > > Unexpectedly, the only way to get the 'expected' result is by adding > additional > > <CR><CR><LF>:... > > image.png > > You've confirmed my understanding of 'infix'; however, not getting > expected results. > > > > Thx - Attila > > > > > > > > On Tue, Apr 19, 2022 at 10:40 AM Steve Lawrence <slawre...@apache.org > > <mailto:slawre...@apache.org>> wrote: > > > > Thanks for the provided schemas. This helps quite a bit. > > > > In this case, the "record" element does not consume the final CR CR > LF > > because it is an infix separator, as you expect. > > > > However, you have an CR CR LF separator on the outer sequence on > line > > 33, so you have something like this: > > > > <xs:sequence dfdl:separator="%CR;%CR;%LF;" > > dfdl:separatorPosition="infix"> > > <xs:sequence> > > <xs:element name="MU16Type" ... /> > > </xs:sequence> > > <xs:element name="trailing-rec" ... /> > > </xs:sequence> > > > > So this expects a CR CR LF in between your MU16Type element and a > > trailing-rec element. That is what actually consumes the final CR > CR LF > > and then the trailing-rec element happily consumes no data and you > get > > the NIL element. > > > > So the suggestion if you want the CRCRLF element to be parsed in the > > tailing-rec is to remove the CR CR LF separator from the outer > sequence. > > Note that things get a bit tricky if you do that. In that case, the > > final trailing CR CR LF is not consumed as an infix separator, as > > expected. And then we do get a single trailing-rec element that > consumes > > the CR CR LF and we get the <CRCRLF> element. But then because > > trailing-rec is unbounded, and happy to try to parse more > trailing-rec > > elements. But a trailing-rec element can consume no data because of > the > > NIL element. This would mean Daffodil could get stuck in an infinite > > loop happily consuming no data. Daffodil detects this and errors > with a > > "No forward progress" message. Simply removing the NIL element from > the > > TailType-TLE fixes this issue, this way it's not possible for > > TailType-TLE to consume no data. > > > > - Steve > > > > > > On 4/19/22 10:12 AM, Attila Horvath wrote: > > > ALCON > > > > > > Same question/issue - see attached samp schema/data. > > > > > > Thx - Attila > > > > > > On Tue, Apr 19, 2022 at 10:03 AM <some...@apache.org > > <mailto:some...@apache.org> <http://apache.org <http://apache.org>>> > wrote: > > > > > > > > > > I can't reproduce this with simpler examples. Can > you > > provide your > > > > actual schema/data? > > > > > > > > > > >
