For new extensions, it's completely reasonable to have defaults if the property is not defined. In this case, both properties should default to "implicit" so as to maintain existing behavior.
A good example of this is the bitOrder property in the BitOrderMixin.scala file. This defaults the property to MostSignificantBitFirst if it's not defined. In addition to setting a default value, that code also defines a tunable that says whether this default should be used when the option is not provided or if the property is mandatory. This is useful so that in future version of DFDL when the property is required we can easily enforce that by toggling the tunable value. Another example that is a little less complex is the defaultParseUnparsePolicy in ElementBase.scala. - Steve On 3/27/19 11:11 AM, Sloane, Brandon wrote: > As part of adding enum support to Daffodil (see proposal > here<https://cwiki.apache.org/confluence/display/DAFFODIL/Proposal%3A+Feature+to+support+enumerations+and+typeValueCalc>), > I am adding attributes to xs:choice (in particular, choiceBranckKeyKind and > choiceDispathKeyKind). > > > The issue that I am running into is, given the design of DFDL, these > attributes must have a value. Normally, this is solved by having schema > define default values for this type of attribute once in a format annotation > and then only explicitly define them again when that default is incorrect. > However, this approach does not work for DFDL extensions, as it would break > pre-existing schemas that do not define values for these attributes. Is there > a mechanism to provide built-in defaults? > > > Regards, > > > Brandon T. Sloane > > Associate, Services > > bslo...@tresys.com | tresys.com >
