Default attribute values

["Sloane, Brandon" <bs...@tresys.com>]

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

bsloane@tresys.com | tresys.com

Re: Default attribute values

[Steve Lawrence <sl...@apache.org>]

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
> 
> bsloane@tresys.com | tresys.com
>