ISO 20022 datatype "identifer set" versus Orchestra discriminator fields

[kleihan]

Section 3.8.5 Discriminator fields defines fields that link to another field to limit its range of values:

FIX contains fields for which its value domain is modified by another
field. This is variously called a choice, discriminated union, tagged
union, or variant. The field that modifies the range of values of
another field is called a discriminator. For example, SecurityIDSource
is the discriminator for the values of SecurityID. If the value of
SecurityIDSource is 4, then the value of SecurityID must be a valid
ISIN, and so forth. This relationship may be indicated in Orchestra by
adding the attribute discriminatorId to a field.

This is a topic for the Orchestra mapping discussion: in ISO 20022 they have commonly used a datatype called "identifier set" that serves the same purpose. The discriminator is a member of the datatype. The difference is that the structured datatype belongs to a single field, not across two fields as in tag value encoding.

This issue was initially proposed by @donmendelson.

[martinswanson]

The ISO 20022 Metamodel defines:

• CodeSet - Complete and enumerated set of Codes grouped together to characterise all the values of an attribute.
• IdentifierSet - Unenumerated set of values outside the Repository whereby each value distinguishes uniquely one instance of an object within an identification scheme from all other instances of the objects within the same scheme. Has a single mandatory property called identificationScheme - Uniquely identifies a set of identifiers through a URI.

In the cited example of SecurityID and SecurityIDSource, it is not clear to me what the proposal is for discriminators, nor whether the term "discriminator" is referring to:

• the SecurityIDSource field
• the list of values defined by SecurityIDSourceCodeSet
• an instance of a code defined by SecurityIDSourceCodeSet

I do think it would be useful to identify external codesets in Orchestra, as distinct from codesets defined within the Orchestra specification itself. That would allow mapping implementations to optionally validate data content against the external values.

[donmendelson]

@martinswanson, the discriminator in Orchestra is logically equivalent to IndentificationScheme in ISO 20022 IdentifierSet. We are using field attributes to tie two fields for lack of that datatype.

Example from the v1.0 spec:

<fixr:field added="FIX.2.7" id="48" name="SecurityID" type="String"
abbrName="ID" discriminatorId="22">
	<fixr:annotation>
		<fixr:documentation purpose="SYNOPSIS">
Security identifier value of SecurityIDSource (22) type (e.g. CUSIP, SEDOL, ISIN, etc). Requires ecurityIDSource.
		</fixr:documentation>
	</fixr:annotation>
</fixr:field>

Orchestra supports external codesets. See External code sets in the spec.

[martinswanson]

Seems a specUrl can only be defined on appinfo or a codeset currently, and is meant for linking to general purpose documentation rather than an actual codeset?

I was thinking we might want the ability to link to an actual codeset defined externally (e.g. in another hosted spec) and, where the discriminator is a codeset, to define such links at the code level.

I've added a crude example to illustrate:

<fixr:field abbrName="Ctry" type="Country" id="421" name="Country" discriminatorId="1234">
    <fixr:annotation>
        <fixr:documentation purpose="SYNOPSIS">
            ISO Country Code in field</fixr:documentation>
    </fixr:annotation>
</fixr:field>

<fixr:field abbrName="InvestorCtryOfResidence" type="Country" id="475" name="InvestorCountryOfResidence" discriminatorId="1234">
    <fixr:annotation>
        <fixr:documentation purpose="SYNOPSIS">
            The ISO 3166 Country code (2 character) identifying which country the beneficial investor is resident for tax purposes.</fixr:documentation>
    </fixr:annotation>
</fixr:field>

<fixr:codeSet name="CountryCodeSourceCodeSet" id="1234" type="String">
    <fixr:code name="ISO3166Alpha2CurrencyCode" id="1" identificationScheme="uri/iso3166/1/alpha-2">
        <fixr:annotation>
            <fixr:documentation purpose="SYNOPSIS">
                ISO 3166-1 alpha-2
            </fixr:documentation>
        </fixr:annotation>
    <fixr:code name="ISO3166Alpha3CurrencyCode" id="2" identificationScheme="uri/iso3166/1/alpha-3">
        <fixr:annotation>
            <fixr:documentation purpose="SYNOPSIS">
                ISO 3166-1 alpha-3
            </fixr:documentation>
        </fixr:annotation>
    </fixr:code>
</fixr:codeSet>

[kleihan]

@martinswanson this would require a change to the usage of the discriminatorId attribute. It is defined as follows today:

		<xs:attribute name="discriminatorId" type="fixr:id_t">
			<xs:annotation>
				<xs:documentation>Identifies a field used as a discriminator for this field's domain
				</xs:documentation>
			</xs:annotation>
		</xs:attribute>

The spec defines it as follows:

FIX contains fields for which its value domain is modified by another field. This is variously called a choice, discriminated union, tagged union, or variant. The field that modifies the range of values of another field is called a discriminator. For example, SecurityIDSource is the discriminator for the values of SecurityID. If the value of SecurityIDSource is 4, then the value of SecurityID must be a valid ISIN, and so forth. This relationship may be indicated in Orchestra by adding the attribute discriminatorId to a field.

Hence it points to a field and FIX uses it to refer to a field with a code set as datatype. The Orchestra schema does not enforce the referenced field to have a code set, i.e. it seems undefined what happens when you reference a field with, for example, a String datatype. A FIX-specific validator could check whether the datatype is a code set and raise an error when this is not the case.

If I understand your example above, you are suggesting discriminatorId to point directly to a code set instead of requiring a field having that code set as datatype. How would you express that InvestorCountryOfResidence uses alpha-2 (code value "1") or alpha-3 (code value "2")? In your example, I would have expected to see a field CountryCodeSource with the datatype CountryCodeSourceCodeSet. That field would then contain the value "1" or "2" to define the external identification scheme.

The attributes specURL and discriminatorId cover different use cases. The existing schema supports external references for entire code sets with the specURL attribute. The attribute discriminatorId sits above that as it points to a field with a code set that may then be external due to the presence of specURL. On the level of a single code of an internal code set (e.g. SecurityIDSourceCodeSet) you need to use an annotation with a nested appinfo element to contain a specURL attribute that points to the external code set. Having a new identificationScheme attribute directly as part of the code element would be easier to understand. The specURL attribute inside appinfo should then be generic and about any kind of information related to the code.

As a consequence, I would then propose to add a new identificationScheme attribute also for the codeSet element to be used instead of the existing specURL attribute.