Support for concept hierarchies

[kleihan]

The Orchestra element concept supports the identification of semantics. A concept can be tied to any number of messages, groups, components, and fields. It is proposed to add the possibility of nesting concepts to support a hierarchy.

A use case is the ISO 20022 Business Model that supports the nesting of business components, i.e. a component may inherit attributes from another component. For example, the concept of a "SecuritiesOptionTrade" has a component "Option" in addition to the concept of a "SecuritiesTrade". This could be expressed as follows in Orchestra:

<fixr:concept name="SecuritiesOptionTrade">
   <fixr:componentRef id="..." name="Option" presence="required"/>
   <fixr:conceptRef name="SecuritiesTrade"/>
</fixr:concept>

<fixr:concept name="SecuritiesTrade">
    ...
</fixr:concept>

Addiitonally, many components in the ISO 20022 Logical Model trace to components in the Business Model. They are not component subsets but express a semantic relationship. This can be made part of the hierarchy by providing a concept attribute to the definition of an Orchestra component, e.g.

<fixr:component name="PercentagePrice1" id="..." concept="SecuritiesPricing">
    ...
</fixr:component>

[kleihan]

Orchestra Subcommittee July 15:

• Recommends disambiguation of components that are used for concepts and those that are not
• Recommends to identify concept references as going "up" (a.k.a. supertype) or "down" (a.k.a. subtype) in a concept hierarchy
• Considers current Orchestra concept model to be lightweight, i.e. additional extensions needed to fully support the complexity of the ISO 20022 business model
• Recommends further analysis of the issue before taking a decision on its inclusion into RC4

[kleihan]

The original idea of a concept was to express semantics where the modelling changes over time. The RC3 spec provides two different examples from the FIX Protocol for this:

1. A Program Order is initially defined by a single field and then changed to a definition using two fields.

<fixr:concept name="ProgramOrder"> 
  <fixr:fieldRef id="47" presence="constant" value="D"/> 
</fixr:concept>

<fixr:concept name="ProgramOrder"> 
  <fixr:fieldRef id="528" presence="constant" value="P"/> 
  <fixr:fieldRef id="529" presence="constant" value="1"/>
</fixr:concept>

2. A message name changes from one version to another

<fixr:concept name="BaseOrder"> 
  <fixr:messageRef id="14" name="OrderSingle" msgType="D"/> 
</fixr:concept>

<fixr:concept name="BaseOrder"> 
  <fixr:messageRef id="14" name="NewOrderSingle" msgType="D"/>
</fixr:concept>

The idea is that two Orchestra XML files define the same concept name but with different definitions. This allows a machine-readable conversion from one logical model to another. This is a different use case that should still be supported when making any changes. A new attribute may be useful to disambiguate concepts for a logical model as opposed to concepts for a business model.

The existing Orchestra concept model can reference any number of messages, groups, components, and fields. They all pertain to a logical model. The ISO 20022 Business Model uses element types components (a.k.a business components) and fields (a.k.a. business elements) and does not have any messages. Re-using the existing Orchestra element types creates an ambiguity as stated above.

There are two fundamental options to remove this ambiguity:

1. Add an attribute to the component definition, e.g. model="Business", defaulting to model="Logical"
2. Add new a element type, e.g. businessComponent

The first option is small change whereas the second option allows for a cleaner separation from the currently supported logical model. The main question is whether Orchestra should be able to support both a business and a logical model. Please provide your thoughts below.

[martinswanson]

My understanding of concept is that its original purpose was to express semantic equivalence as logical models evolve over time. For example, if a message or field changes between versions, a concept provides a stable semantic identity that allows relationships to be established across different logical representations.

The current proposal appears to broaden the role of concept from expressing semantic equivalence between logical models to representing reusable business domain objects and their relationships. This is a significant extension of its responsibility.

For example, NewOrderSingle does not currently define a separate Order component; instead, the attributes of an order exist directly at the top level of the message. An alternative modelling approach would be to introduce an explicit Order component that could be reused by messages such as NewOrderSingle and NewOrderList. Component scenarios could then be used to model variations for different asset classes, as well as request/response message types. This could remain entirely optional, allowing users to continue with the existing flat message structure or adopt explicit reusable business components where they provide additional value.

If Orchestra is to support both a business model and a logical model, it would be useful to understand the trade-offs between using concept to represent reusable business domain objects versus modelling those objects explicitly as reusable business components, with concept continuing to serve its original purpose of expressing semantic equivalence across logical models.