Add code set attributes to define length and range of values

[FIXdom]

ISO 20022 supports internal and external code sets. Internal code sets are defined by a list of supported values. External code sets additionally define the minimum and maximum length of codes, e.g.

    <xs:simpleType name="ExternalAccountIdentification1Code">
        <xs:restriction base="xs:string">
            <xs:minLength value="1"/>
            <xs:maxLength value="4"/>
            <xs:enumeration value="AIIN">
            ...

Orchestra supports length information on the field level with the attribute group fieldAttribGrp and attributes implLength, implMinLength, and implMaxLength. The inability to define this for a code set requires to define it explicitly for every field using the code set. Field attributes also include the lower/upper bound of field values (minInclusive, maxInclusive), which also make sense for a code set.

[JamieOBE]

Hi @kleihan - the characterisation of ISO 20022 CodeSets here is not exactly correct - sharing a more precise view on the ISO 20022 CodeSet metamodel that may reveal a way forward more clearly than trying to reverse-engineer from an xsd.

Look at the white DataTypes at the bottom of the attached graphic - As you can see, CodeSet types are technically no different in their cardinality than any other String (Like Text types e.g. Max35Text and IdentifierSet types)

They all inherit their (optional) min/max/length/pattern facets from their common (abstract) superType, String.

The presence or absence of these facets has no bearing on whether a CodeSet is Internal or External - Neither does the presence or absence of actual Codes to enumerate the supported values.

In the current ISO 20022 v1.5 model, the only way to determine if a CodeSet is External is that its name starts with "External" (E.g. "ExternalClearingSystemCode1")

In the 2.0 metamodel, I believe that an additional Boolean isExternal attribute has been added to make this explicit, but I don't believe that the fundamental concept of CodeSet/Code has changed much... NOTE: To be confirmed with Jason Polis who was more closely involved in the 2.0 revision - because of the move to ISO 11404 general purpose datatypes, this might have changed. (BTW, I notice that I can't tag Jason here - can we add him to this repo?)

Anyway, in summary - for me, we should be able to map any CodeSet DataType with its min/max/length/pattern properties into Orchestra in the same way that we mapped the Max35Text DataType into Orchestra...

Of course, then we need to work out how to associate any Codes to their owning CodeSet - In ISO 20022, this is managed via an "owner" reference on each Code that points to its CodeSet.

If we need to map directly to Orchestra's Code/Set concept, then maybe these details will help us identify the best way to achieve this - or at least help identify where Orchestra might evolve to make it easier in future...

Hope this helps? Happy to try clarify or dig deeper if needed

Cheers
Jamie

[JasonPolisAdmin]

ISO 20022:2026 formalises the current practice of a 2 layer codeset model:

• that a logical CodeSet traces to a conceptual BusinessCodeSet
• that an empty code set is "external", dynamically referencing another codelist at run time, rather then including values in a message schema.

The logical CodeSet has a boolean attribute "reference" to indicate whether its "identificationScheme" attribute is a reference to an external code set.

Its other facet attributes for length and pattern are inherited from Text, rather then String.

[FIXdom]

ISO 20022 seems to limit values of code sets to Strings (or Text). Orchestra does not have that limitation, i.e. the type attribute of a code set definition can reference any valid datatype name (it must actually be defined):

<xs:keyref name="codeSetTypeKeyRef" refer="fixr:datatypeKey">
  <xs:selector xpath="fixr:codeSets/fixr:codeSet"/>
  <xs:field xpath="@type"/>
</xs:keyref>

[FIXdom]

Suggest to discuss the merits of the issue once more. A code set defines the list of possible values. In case of strings, their minimum/maximum length can be derived from the actual values. In case of numbers, their minimum/maximum values can also be derived from the actual values. The availability of fieldAttribGrp for code sets could make sense to set boundaries for new values being added to a code set. For example, setting the length to min=max=4 would mean that string values must always be 4 characters long.

This information would not be relevant when validating the wire format, i.e. it is only useful during the design process. However, design guidelines are unlikely to be defined on the level of an individual code set, e.g. all codes must be 4-letter acronyms. The ISO 20022 example above has this information, but the question remains whether it really adds value to a code set definition.