I did test this against IBM DFDL, and the infoset does match what I suggested. So I think I have answered my own question by verifying against IBM. Mike Beckerle | OGF DFDL Workgroup Co-Chair | Owl Cyber Defense | www.owlcyberdefense.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php> On Wed, Apr 21, 2021 at 12:08 PM Mike Beckerle <mbeckerle.dfdl@gmail.com> wrote:
An earlier email I sent had this schema:
<xs:element name="file1"> <xs:complexType> <xs:sequence dfdl:separator="," dfdl:separatorPosition="infix" dfdl:separatorSuppressionPolicy="never"> <xs:element name="given-name" type="xs:string" minOccurs="0" maxOccurs="3" /> <xs:element name="surname" type="xs:string" minOccurs="0"/> <xs:element name="phone" type="xs:string" minOccurs="0" maxOccurs="6" /> </xs:sequence> </xs:complexType> </xs:element>
Given that, and a default dfd:format with occursCountKind='implicit' I expect this data:
"madonna,,,,,,,,,"
To produce this DFDL Infoset (cast as XML):
<file1> <given-name>madonna</given-name> </file1>
I don't expect to see any empty elements like <given-name></given-name> because all elements are optional, so a zero-length representation for a xs:string is the Empty representation, and optional empty is never added to the infoset.
Furthermore, this should "round trip" i.e., unparse back to the original input data.
Am I correct here?
Mike Beckerle | OGF DFDL Workgroup Co-Chair | Owl Cyber Defense | www.owlcyberdefense.com Please note: Contributions to the DFDL Workgroup's email discussions are subject to the OGF Intellectual Property Policy <http://www.ogf.org/About/abt_policies.php>