Thanks again Steve. Just to be certain that I understand, the rule is this:
Scenario: A field named FOO consists of several parts, A, B, C, D. The last part – D – is followed by the field’s delimiter. No padding or fill is added to the last part on uparsing. If you want padding/fill added after D on uparsing, then you must specify dfdl:fillByte="%SP;" at the higher level, i.e., on the element declaration for FOO. Is that correct? /Roger From: Steve Lawrence <slawre...@apache.org> Sent: Friday, January 19, 2024 10:54 AM To: users@daffodil.apache.org Subject: [EXT] Re: Sometimes unparsing pads with spaces, sometimes with zeroes - why? Because RunwayDesignator_2 is delimited no padding or fill is added on unparsing, so setting fillByte or textPadKind won't have any affect. The space actually being filled is part of the RunwayDirectionDesignator element (it's technically the Because RunwayDesignator_2 is delimited no padding or fill is added on unparsing, so setting fillByte or textPadKind won't have any affect. The space actually being filled is part of the RunwayDirectionDesignator element (it's technically the "ElementUnused" portion of the complex type, which exists when the children don't fill the full length of the parent). So the fillByte property needs to be specified on that element instead. On 2024-01-19 10:43 AM, Roger L Costello wrote: > 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<mailto:slawre...@apache.org>> > *Sent:* Friday, January 19, 2024 10:19 AM > *To:* users@daffodil.apache.org<mailto: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/ >> <http://www.ogf.org/dfdl/<http://www.ogf.org/dfdl/%20%3chttp:/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> > >> >
