Consider adding section as an attribute to components

[jimnup]

Background:

FIX repository elements are organized into sections (which have some affinity to business process - although this is difficult to reify)
Current sections are: {Pretrade,Trade, PostTrade, Infrastructure}

Entities in the repository are further segmented into categories which relate to specific business processes (again another difficult term to fully define), such as {SingleGeneralOrderHandling, ProgramTrading, OrderMassHandling, CrossOrders, MultilegOrders} within the Trade section}.

Components are scoped at three levels within FIX:

• global (referred to as common components since 4.3)
• common (shared across) across multiple categories within a section such as Trade/Common
• within a specific message category such as Trade/MultilegOrders

Unfortunately only the category attribute is carried for a component entity in FIX in the Orchestra repository (as was the case since the Unified Repository was introduced).

This proposal is two fold. First it is to add the section to the component in addition to the category.

The second part of the proposal is to add a new section "Global" for global components and messages. Category to remain "Common".

Section=Global Category=Common would be for components that are global across all sections and category.

[kleihan]

Section=Global Category=Common would be for components that are global across all sections and category.

Component should be global as soon as it is used in more than one section, not necessarily all of them.

[kleihan]

There are currently more than 500 components that are considered global. A single category "Common" is not enough to structure them, e.g. for documentation purposes. One approach would be to introduce entities as category names, e.g. "Instrument", "Party". Another approach is to add another attribute below category for that, e.g. "subcategory".

A subcategory can also be used for pre-trade, trade, post-trade, e.g. to identify the type of message as "Request", "Report", "Acknowledgement". This may make it easier to formalise workflows. Could then also apply to all components (global or not) to refer to the main entity it is about, enabling a semantic grouping of components. Example: subcategory "Allocation" for PreAllocGrp, TrdAllocGrp, etc. subcategories would hence not be limited to a single section.

In short, IF we decide to add an attribute, we could add more than one without increasing effort for us and impact to the community.

[jimnup]

If we introduce Section and Category as attributes of components, I would have no issue of creating additional categories to group the Global (common) components into semantic groupings, such as Parties, Instruments, etc. This would be quite helpful in my opinion and would not in my opinion cause a problem with the concept of "category" as we use it. In fact, it seems consistent with the semantics beneath the "category" attribute. Whether we tag categories specifically for components as being component categories - that is worth a discussion, I don't see a need because you can ask the repository a question: "What entities are associated with this category?",. (An Aside: I am looking forward to when we release the RDF/OWL/SKOS Orchestra representation of the FIX Repository in 2021 so we can easily ask such questions using SPARQL.)

[donmendelson]

Reacting to @jimnup's aside... Yes, categorization of message elements by business area/process is a taxonomy, isn't it, a job that semantic notation is suited for.

• The levels of categorization need not be fixed to a set number.
• We could create the taxonomy in semantic notation, then come up with a syntax to flatten it for purposes of the XML schema.

[martinswanson]

The FIX Protocol subcommittee is tasked with improving the user search experience across various types of documentation, including FIX specifications and Recommended Practices. As part of this effort, we have examined how ISO 20022 structures its documentation and considered how the ISO 20022 Metamodel might inspire improvements for Orchestra.

ISO 20022 provides two distinct types of categorisation that we should consider:

1. Categorisation of messages by BusinessArea: In ISO 20022, this follows a simple two-tier model, similar to Orchestra's Section/Category model, and is strictly aligned with the logical layer.

Example: SECURITIES / Securities Settlement (sese)

See: ISO 20022 Business Areas

2. Categorisation of message elements and components by BusinessElement / BusinessComponent: This is aligned with the conceptual layer.

I believe ISO 20022 is correct in modelling the categorisation of messages separately from that of message elements/components, for the following reasons:

• Messages are tied to the logical layer and belong to one, and only one, BusinessArea (Section/Category).
• Message components/elements are part of a business domain model or data dictionary, which can be used in multiple messages and are not limited to a single BusinessArea (Section/Category).

This distinction is important because the categorisation of a component/element depends on the context of its usage within a specific set of messages, and this can change when messages are updated or new ones are added. For example, a component classified as "common" within PreTrade may need to be reclassified as "global" if it is later used in another section.

Using Section/Category to categorise components/elements presents several significant disadvantages:

• Maintenance burden: The categorisation would likely need to be updated whenever messages are added or modified.
• Customisation challenges: Users creating their own Orchestra specifications with the FIX data dictionary would need to manually update categorisation, especially when using tools like Tablature that copy base elements from a reference specification.
• Limits on documentation generation: It would prevent users from generating their own documentation for any set of messages.

Currently, I am only aware of the following uses for Section/Category:

• FIXimate: Organises messages into "Message Layouts" using Section/Category.
• FIX normative documents: Messages are grouped by Category and split by Section.
• FIX normative documents: Components are grouped within a category.

The first two uses pertain to message categorisation, while the third could be replaced by any documentation tool capable of dynamically computing the categorisation of components/elements based on their usage within a specific message set.

Proposal

• Limit the use of Section/Category to organising messages only.
• Do not apply sections to components.
• Remove categories from components.
• Allow document generation tools to dynamically categorise components/message elements depending on the scope of messages being documented.

If accepted, we could remove the categoryType attribute from categories (I have only ever seen it set to "Message" in practice). Relevant to issue #191.

<xs:simpleType name="CatComponentType_t">
      <xs:restriction base="xs:string">
	      <xs:enumeration value="Field"/>
	      <xs:enumeration value="Message"/>
      </xs:restriction>
</xs:simpleType>

The broader question of how to categorise components/elements at the conceptual level is crucial and should be addressed separately, using the ISO 20022 Metamodel for inspiration. As @jimnup suggests, it may be better to use a known semantic standard such as RDF/OWL to model the conceptual layer.