Well, the good news is that your 3rd item, about allowing hyphens (or non ES generally) as nilValue for complex type elements is targeted for release 3.4.0 of daffodil as an experimental extension to DFDL which assuming it works out, we would propose for inclusion in a future DFDL revision. (Now we just have to find someone to work on it!) It is ticket https://issues.apache.org/jira/browse/DAFFODIL-2636
As for minOccurs 0 on model groups. 3 arguments against it. 1) added complexity 2) Too XML centric/specific 3) Technical issues associated with multiple points of uncertainty (for choices) So (1) Sequences can't have minOccurs="0" for simply the reason that DFDL is complex already. Adding array/optional behavior to anonymous model groups is very problematic. One example area is expressions. Allowing repeating or optional anonymous groups complicates path expressions immensely. DFDL indexing is dead simple in comparison to XPath "indexing", which can't really be compiled easily. XPath indexing is much more like a query than like array element access. They don't even call it indexing, they call it "predicates". DFDL path expressions are always executable in constant time, or that was the intention anyway. Each step of a path expression is either up, down to a named scalar child element, or down to a single specific index in a named array/optional. All steps can be compiled to tiny non-complex operations. By comparison, XPath indexing is O(n) in the size of the data, and can return a node list that is O(n) in size. Re: (2) Note that anonymous things that are arrays or optionals are not a feature of any structured data format notation I know of, *except* XML. There are numerous other XML-isms that were rejected in DFDL e.g., no attribute children of elements. Again this is because there is no structured data format notation that allows two different kinds of children with separate namespaces except XML. re: (3) Choices can't have minOccurs="0" because then there would be two points of uncertainty in one location. Does a dfdl:discriminator discriminate both, or just the choice, or just the optionality? Now, DFDL is an "open" standard, and if people want to participate in the DFDL workgroup directly, and evolve the standard to better accomodate the needs of XML users, then that's certainly one direction it could go in. Apache Daffodil is an open-source implementation suitable for prototyping and it goes in the direction its developers take it. We acknowledge the fact that XML users find DFDL restrictive compared with XSD, but we balance that against the fact that numerous people find DFDL far too XML oriented and complex. This is reflected in our Apache Daffodil Roadmap ( https://cwiki.apache.org/confluence/display/DAFFODIL/Roadmap+for+Upcoming+Releases). Software developers definitely have a love or hate relationship with XML and there is little middle ground. See specifically sections of the Roadmap titled: "XML Feature Enhancements (and JSON)" and "Escape from XML - A Non-XSD Syntax for DFDL". On Fri, Mar 25, 2022 at 7:46 AM Roger L Costello <coste...@mitre.org> wrote: > Hi Folks, > > I am converting 350 military data formats to DFDL. > > Everyone of the 350 data formats has an optional choice: > > <xs:choice minOccurs="0"> > > DFDL does not allow optional choice. Why? > > I recommend changing the DFDL language to allow optional choice. > > Everyone of the 350 data formats has branches of a choice that are > optional: > > <xs:choice> > <xs:element name="foo" minOccurs="0"> > > DFDL does not allow branches in a choice to be optional. Why? > > I recommend changing the DFDL language to allow optional branches of a > choice. > > Many of the 350 data formats have an element with complexType that is > nillable and the nilValue is a hyphen. > > DFDL does not allow an element with complexType to have a nilValue other > than %ES; > > I recommend changing the DFDL language to allow elements with complexType > to have a nilValue other than %ES; > > /Roger >
