Relationship between field and type

[donmendelson]

In Orchestra version 1.0 abstract metamodel, a field has a type (as well as other attributes such as name and id). Type refers to a datatype. Also, in the metamodel a code set is defined as a specialized datatype with a finite set of valid values. In other words, a code set is-a datatype, abstractly. Thus, the type attribute can refer to either a datatype or a code set.

The version 1.0 XML schema enforces that type refers to either a datatype or code set element. A broken link will be reported by an XML processor.

Nevertheless, some developers have found this relationship confusing. The proposal is to make type attribute refer only to a datatype or the underlying datatype of a code set, but not to the code set itself. Rather, a second optional attribute will be added if a field has a code set to give the ID of that code set.

In the abstract sense, a code set will be thought of as has-a constraint of a datatype rather than is-a datatype.

[donmendelson]

As described above, the v1.0 design was predicated on the idea that a code set is-a datatype in that it is another way to specify a data domain. A change in v1.1RC1, repositorySchema: datatypes lack scenarios #151, actually reinforces that idea by better aligning code sets and datatypes. That change causes a complication for this proposal.

In the v1.1RC1 design, a field has a one concatenated key type+scenarioId to refer to either a code set or a datatype scenario. (Scenario defaults to "base".) But if a field is to optionally have both a code set and a datatype, it would have two cross-references:

• type+scenarioId to refer to a datatype
• codeset+scenarioId to refer to a code set

The problem is that the datatype scenario and the code set scenario may not be the same scenario. It is clear why we have scenarios for code sets--there are code sets that are related semantically and have the same name but have slightly different sets of codes for different use cases. We have now also introduced scenarios for datatypes. I can imagine a code set that use a datatype scenario as its underlying type, e.g. a short int.

Therefore to separate datatype from code set, we need two additional attributes on a field:

• name of a code set (optional)
• scenarioID of a code set

Issues

Note that the code set scenario cannot default to the "base" scenario like the type reference since code set is optional. It must populated if code set name is populated, even for "base" scenario.

In the v1.0 and v1.1RC1 designs, the type/code set reference is enforced by the XML schema by a single keyref. We can still enforce the datatype reference, but since code set is optional for a field, we cannot enforce its validity in the XML schema. (It may be possible in XML Schema v1.1 with assertions, but we have already determined for other reasons that we cannot use it.) This is likely to allow errors in the future Orchestra files.

[kleihan]

To be confirmed if FIXTradingCommunity/fix-orchestra#170 has fully covered this issue in terms of schema changes. RC1 has both a type and a codeSet attribute for a field that are intended to be mutually exclusive. I believe that the schema cannot enforce that, i.e. it needs to be defined in the spec.