Thanks Steve. Sure enough, the defaults file had fillByte="0" and when I changed it to %SP; then uparsing worked as desired.
Why it is that if I leave the defaults file as is, and add dfdl:fillByte="%SP;" to RunwayDesignator_2, I get the incorrect result on unparsing? /Roger From: Steve Lawrence <slawre...@apache.org> Sent: Friday, January 19, 2024 10:19 AM To: users@daffodil.apache.org Subject: [EXT] Re: Sometimes unparsing pads with spaces, sometimes with zeroes - why? My guess is that the default lengthKind is delimited and the default fillByte is the zero character? If this is the case, then RunwayDesignator_2 is delimited and no padding will be output when unparsed. But the parent RunwayDirectionDesignator My guess is that the default lengthKind is delimited and the default fillByte is the zero character? If this is the case, then RunwayDesignator_2 is delimited and no padding will be output when unparsed. But the parent RunwayDirectionDesignator element has an explicit length of 7. So if its children (RunwayDesignator_1, _2, and the hyphen) don't unparse to 7 characters then the remaining characters will be filled with the fillByte. If your probably seeing zeros because fillByte="0". The easiest fix is likely to just change the default fillByte to a space, i.e. fillByte="%SP;" On 2024-01-19 09:56 AM, Roger L Costello wrote: > My input is a 7-character, fixed length field. > > The field contains data about one or two airport runways, e.g., > > .../24L-36R/... > .../24L /... > > The L and R are optional, so the field could be these: > > .../24 /... > .../24-36 /... > > My DFDL schema parses correctly and mostly unparses correctly, but for > that last example it adds two zeroes instead of two spaces on unparsing. > > These: > > .../24 /... > .../24-36 /... > > parses to these: > > <RunwayDesignator>24</RunwayDesignator> > > <RunwayDirectionDesignator> > <RunwayDesignator_1>24</RunwayDesignator_1> > <RunwayDesignator_2>36</RunwayDesignator_2> > </RunwayDirectionDesignator> > > And uparses to these: > > .../24 /... > .../24-3600/... > > Notice that spaces are properly added in the first case, but zeroes are > added in the second case. Why is that? Below is my DFDL. > > <xs:choice> > <xs:elementname="RunwayDesignator" > type="RunwayDesignator_simpleType" > dfdl:lengthKind="explicit" > dfdl:length="7" > dfdl:textTrimKind="padChar" > dfdl:textPadKind="padChar" > dfdl:textStringPadCharacter="%SP;" > dfdl:textStringJustification="left"> > <xs:annotation> > <xs:appinfosource=http://www.ogf.org/dfdl/ <http://www.ogf.org/dfdl/>> > <dfdl:assert>{ dfdl:checkConstraints(.) }</dfdl:assert> > </xs:appinfo> > </xs:annotation> > </xs:element> > <xs:elementname="RunwayDirectionDesignator" > dfdl:lengthKind="explicit" > dfdl:length="7"> > <xs:complexType> > <xs:sequence> > <xs:elementname="RunwayDesignator_1" > type="RunwayDesignator_simpleType" > dfdl:lengthKind="pattern" > dfdl:lengthPattern=".*?(?=[-])"/> > <xs:sequencedfdl:hiddenGroupRef="hidden-Hyphen"/> > <xs:elementname="RunwayDesignator_2" > type="RunwayDesignator_simpleType" > dfdl:textTrimKind="padChar" > dfdl:textPadKind="padChar" > dfdl:textStringPadCharacter="%SP;" > dfdl:textStringJustification="left"/> > </xs:sequence> > </xs:complexType> > </xs:element> > </xs:choice> >
