How should we deal with required fields in optional components?

[RichardWarburton]

We currently treat them as required, possibly best to consider them optional?

[juddgaddie]

I am not sure what the meaning optionality has in component. My understanding of components is that they are simply there to give an identity to and therefore inform the type system of a FIX Engine implementation of a group of fields. A component cannot exist on the wire and in a language that has no type system (or uses some sort of duck typing) would not need to care about components. Optionality is something for backward compatibiltiy when decoding messages on the wire.

[RichardWarburton]

@juddgaddie - you're right, it's an ill-defined situation with no clear meaning. But that doesn't mean that people don't have FIX Dictionaries with optional components with required fields in. Currently in that situation Artio treats the field as required, as it conceptually inlines the fields of components.

Issuing a warning when this happens to say that it's ill-defined is an alternative as well.

[writeoncereadmany]

We've seen real messages with groups absent where the spec has an optional component representing a required group, implying that in those contexts this group is intended to be treated as optional.

Which implies that (empirically) optionality dominates over requirement - anything (top-level) inside an optional component is optional? Note that this wouldn't recursively apply to fields within a group entry, but it would apply to a (top-level) group itself?