Scenario Selective Inheritance (SSI) - Technical Proposal Draft. #199
Replies: 5 comments 4 replies
-
|
@francescoloconte: Thanks for working on this, the proposal looks great! I believe it covers all requirements we have been discussing in the calls. It also is much simpler than alternative proposals. The section explaining the algorithm on how scenarios must be constructed should ensure users and vendors are never surprised with the resulting outcome of an inherited object. I like the name because as mentioned in the document it is not pure inheritance, so developers coming from other technologies will fin the emphasis on that distinction useful at the beginning. Also might be worth mentioning, that if someone is not constrained by needing a specific order (FIX Tag Value encoding), they can get pure inheritance at the Message and Component level by just using additions. Agreed that sort needs to be deprecated in CodeSets. I would remove the alternative sorting mechanism from this doc for brevity and clarity. Instead, I suggest to move it to the Comparison with Previous AND Alternatives Proposals at the end. Small typo: After the interleaving explanation there are "Schema Changes" twice. Agreed on not overloading the semantics of supported and presence. |
Beta Was this translation helpful? Give feedback.
-
|
Your suggestions are well taken and I have applied them to the draft above. |
Beta Was this translation helpful? Give feedback.
-
|
Rephrased section 7 to clarify that any attribute may be overridden with exceptions. |
Beta Was this translation helpful? Give feedback.
-
|
Does anyone think that Scenario names should be declared before being used? I.e. should we add a section in Orchestra called "Scenarios", just like we have Sections and Categories? Some of the advantages would be:
Thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
I agree, that would be very useful. |
Beta Was this translation helpful? Give feedback.
-
|
We already added a section called
The schema for v1.1 RC1 has the following first degree elements, it includes scenarios: <xs:element name="metadata" type="dcterms:elementOrRefinementContainer"/>
<xs:element ref="fixr:categories" minOccurs="0"/>
<xs:element ref="fixr:sections" minOccurs="0"/>
<xs:element ref="fixr:datatypes"/>
<xs:element ref="fixr:codeSets" minOccurs="0"/>
<xs:element ref="fixr:fields"/>
<xs:element ref="fixr:actors" minOccurs="0"/>
<xs:element ref="fixr:components" minOccurs="0"/>
<xs:element ref="fixr:groups" minOccurs="0"/>
<xs:element ref="fixr:messages"/>
<xs:element ref="fixr:concepts" minOccurs="0"/>
<xs:element ref="fixr:scenarios" minOccurs="0"/>
<xs:element name="annotation" type="fixr:annotation" minOccurs="0"/>
Each scenario currently has an ID , a name and can have one or more annotations: <xs:complexType name="scenarioType">
<xs:annotation>
<xs:documentation>The use case of an element, distinguished by workflow, asset class, etc.</xs:documentation>
</xs:annotation>
<xs:sequence>
<xs:element name="annotation" type="fixr:annotation" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="fixr:id_t" default="1">
<xs:annotation>
<xs:documentation>Unique numeric identifier. Default is '1' is for base scenario.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="name" type="fixr:Name_t" default="base">
<xs:annotation>
<xs:documentation>Unique name</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:complexType>I agree that all scenarios used for elements should be listed in the section |
Beta Was this translation helpful? Give feedback.
-
|
Changed "List of Abbreviations" to "List of Terms". |
Beta Was this translation helpful? Give feedback.
-
|
Fixed an error:
We don’t support referencing the parent scenario by name.
|
Beta Was this translation helpful? Give feedback.
-
|
I fixed an error as below:
|
Beta Was this translation helpful? Give feedback.
-
Scenarios and Inheritance
Scenarios in Orchestra allow for defining variations of entities. With Orchestra 1.0, a scenario is another instance of its base entity, only sharing their id and name, without other entity relationship. To improve the value of scenarios, a scenario relationship is proposed. This enables a scenario to inherit the structure and attributes of another, modify the structure by adding, removing, and replacing elements, and adjust attributes while retaining a parent/child relationship, where changes to the parent entity are reflected in the child scenarios, similarly to inheritance in object-oriented design.
To implement this inheritance, the addition of
inheritsScenarioIdattribute to theoidGrpis recommended, applicable to all container types, as well asfieldTypeandcodeType.Scenario Selective Inheritance
In the context of object-oriented design and development, inheritance is a mechanism where a new class (subclass) is created, absorbing, and extending the characteristics and behaviors (attributes and methods) of an existing class (superclass). This allows the subclass to reuse code from the superclass and add new functionalities or modify existing ones as needed.
With this type of inheritance is not possible to remove or hide what is being inherited from the superclass. However, in the case of Orchestra, is it desirable to selectively inherit elements from the parent scenario, or in other words, remove inherited elements that are not desired. For this reason, we call our technique Scenario Selective Inheritance (or SSI) since it allows selecting what to inherit from the parent scenario.
[It is important to clarify that the technique does not provide pure inheritance because, by definition, inheritance would require that a child scenario be usable anywhere the parent scenario is usable. Since we allow removal of elements in the child scenario, this is no longer possible. Henceforth the need to use an adequate name.]
List of Terms
Element Additions
A Child Scenario can add new elements that are not present in its Parent Scenario. This is done by referencing the new elements in the scenario definition.
Example
Define Scenario 2 for the Instrument component, adding the MaturityDate field:
Positional Element Addition
Certain encodings, such as FIX tag=value encoding, rely on the ordering of elements, for example, the order of fields in the message. When creating a scenario, it is therefore important to be able to specify where new elements should be added. To address this requirement, we propose a simple approach that uses other elements as anchor points.
The method for placing a new element involves referencing the adjacent element in the parent scenario (anchor), indicating where to position the new element (pivot) relative to the anchor (e.g., before, after, etc.). To achieve this, the following attributes are suggested for referencing existing elements of
messageType,componentType,groupType, orcodeSetType:position: where the new element should be placed, e.g., before the referenced elementpositionRefType: the type of the referenced element (component, group, or field)positionRefId: the identifier of the referenced elementpositionRefScenarioId: the optional identifier of the scenario of the referenced element.Example
Add the tag 20002 after the tag 44:
Since it is not uncommon to add new elements as the first or last one in a container, the position attribute enumeration should include two more options:
firstandlast.When no position attribute is specified, the element is added as the last one in the container.
Note on
instanceNameandpositionRefInstanceNameIn Orchestra, when defining containers such as messages, components, or groups, their constituent elements can reference the same element more than once. For example, a message can reference a field twice (recurring elements). Since references do not have unique identifiers, it would not be possible to tell them apart. Therefore, Orchestra provides the
instanceNameattribute on field reference and component references. This provides further instances of references (to the same element) with a locally unique name.It follows that if a Parent Scenario includes recurring elements, it is necessary to distinguish between them to use them as anchor points. To address this, an additional optional attribute is proposed:
positionRefInstanceName: the optional instance name of the referenced elementThe additional attribute should match the
instanceNameof the referenced element. If there are recurring elements andpositionRefInstanceNameis not specified, it defaults to the original one element.Effect on CodeSet Sort Order
The Code elements in a CodeSet have an attribute called sort to sort them for displaying purposes. However, by supporting scenarios for a CodeSet, when a child scenario adds new Codes, it will not be able to use the sort attribute to interleave them with existing Codes, since sort numbers are contiguous. This renders the sort attribute ineffective.
We recommend therefore deprecating the sort attribute from the Code element, and instead making their order of definition meaningful, even for displaying purposes, just like for fields in messages. It will be possible to use the technique described above to interleave Codes.
Example
Note: nested element
structureofmessageis omitted for simplicity.Clarifications on Usage
Consider the following scenario with fields labeled F1, F2, F3, F4, and F5:
Adding After:
We start with this structure:
Adding F2 after F1, using F1 as the anchor point, results in this:
Adding F3 after F1 should result in:
This method ensures that new fields are incorporated in the order they appear in XML.
Adding Before:
Staring again with this structure:
Adding F2 before F5, using F5 as the anchor point, results in this:
Then, including F3 before F5 should result in this:
Note that in the final result, fields appear in the same descending order as they were added.
Interleaving:
Let's consider the scenario of adding F2 after F1 and F3 before F5:
Lastly, adding F2 after F1, F3 before F5, and F4 after F1 results in:
Following the algorithm, F4 is added after F2, avoiding any interleaving.
Schema Changes:
In
fieldRefType,componentRefType,groupRefType,codeTypeadd the following optional attributes:In
codeType, remove thesortattribute.Element Removals
A Sub Scenario can remove elements that are present in its Parent Scenario. Similarly to how
fieldRefis used to add (by reference) a field, and code is used to define a new value in a codeSet, we propose introducing new element typesfieldUnref/groupUnref/componentUnrefandcodeUndefto unreference and undefine elements and code values respectively.To identify the element to be removed, the new XML elements would have the following attributes:
id: Theidof the element being removed.scenarioId: ThescenarioIdof the element being removed.instanceName: [Optional] TheinstanceNameof the element being removed. Required to differentiate the same element appearing multiple times in the parent scenario.Example
Example
Schema Changes
Schema Changes:
In
messageType/structure,componentType,groupTypeaddfieldUnref,groupUnref,componentUnrefelements.In
codeSetTypeaddcodeUndefelement.Add the following attributes to the new elements:
Notes on
supportedandpresenceattributesWhile removal of elements could be accomplished by manipulating and reusing the existing
supportedorpresenceattributes, we recommend avoiding using these attributes, since they already have a clear semantic, and instead introducing the dedicated approach described above.Element Replacements
A Child Scenario can replace elements that are present in its Parent Scenario. A straightforward approach involves first removing the element being replaced, and subsequently adding it again with the desired modifications. The replaced element can be inserted at the old position or to a new position. If none is specified, it is added as the last entry in the scenario.
Explicit Replacement
Elements are first removed and then added again.
Example:
Redefine a code by altering its value and name.
Example:
Replace field 44 with field 66.
Implicit Replacement
Since
scenarioIdis part of the element's unique key, altering it would essentially replace the element. However, changing the scenario of an element within a child scenario of its container is a common task, and the implicit replacement technique is tailored for this purpose.If the element needing a
scenarioIdchange can be referenced solely by anidwithout ambiguity, the newscenarioIdcan be specified along with other modifications. In such cases, there's no requirement to remove the original element beforehand.Example:
Field 44 has scenarios 1 and 2, and we want to change from 1 to 2, and update its presence too.
Element Attribute Changes
When a child scenario of an entity is defined, its attributes are inherited from the parent scenario. Any attribute except ones from
oidGrpcan be overridden in the child scenario. However, in most cases, some attributes, likemsgTypeorcategory, should not be changed.If the child scenario of a container (e.g.,
component) includes a reference which matches an existing reference in the parent scenario byid,scenarioId, andinstanceName, then all the rest of the attributes are inherited from that reference. Any attribute exceptidandnamecan be overridden. Changing the scenario of the reference is a special case of element replacement addressed in section 6.2.Annotations, rules, and assignments are inherited in the same way, and can be overridden by redefining them in a child scenario.
Example
Change optional field to required, change scenario and synopsis of component.
It's important to note that changing the
scenarioIdentails nuances since it involves replacing the element reference with another one (refer to the "Implicit Replacement" section above).Example
Define a scenario of a field with a constraint to its length, and a modified annotation, inheriting all other attributes.
Handling Parents Changes
When changes are made to a Parent Scenario, its Children Scenarios will be affected as it follows:
Algorithm for SSI Processing
When processing the definition of a scenario, the following rules should be observed.
Comparison With Previous Proposals
A previous technical proposal called "Include Scenarios with Exceptions”, in section 4.3 allowed using scenarios as building blocks to other scenarios, similarly to how components are used to build messages. This would enable for example the use of different scenarios of the same element (e.g., A and B) to build a new scenario of the element (e.g., C = A + B), while providing control over the placement of new elements, but also requiring removal of duplicate elements from the addends.
While this technique offers flexibility, it approaches scenarios as building blocks for other scenarios, similarly to how existing FIX components are used. To achieve this, a scenario would not inherit anything from its parent, but instead it would re-define its structure using data from the parent, through direct references to it (as a building block).
In our opinion, this technique approaches scenarios differently from their original ethos, where scenarios are assumed to be slightly different versions of their parent.
We think the techniques described in this paper (Scenarios Selective Inheritance, or SSI), where scenarios inherit the structure of their parent, which is then modified with simple instructions, is simpler.
A criticism voiced toward SSI is that it could be used to modify scenarios to such an extent they have no resemblance to their parent. However, the potential for misuse of any technique is impossible to remove, and in fact this is already possible with the current Orchestra scenarios. However, since SSI instantiates scenarios with the full structure inherited from their parent, it has the benefit of precluding scenarios from being used as a building blocks.
Additionally, when adding fields to the middle of a scenario, the previous proposal required breaking the parent scenario into parts first. Our proposal offers a simpler approach.
Additionally, SSI has the following additional advantages:
Comparison Table
scenarioRefto the possible elements ofmessageType,componentType,groupType,codeSetType.excludeinside of the elementscenarioRefto restrict the elements to be included from the scenario.baseScenariotomessageType,componentType,groupType,codeSetType.fieldUnref,componentUnref,groupUnrefto the possible elements ofmessageType/structure,componentType,groupType.codeUndefto the possible elements ofcodeSetType.position,positionRefId,positionRefScenarioId,positionRefNametofieldRefType,componentRefType,groupRefType,codeType.positionRefTypetofieldRefType,componentRefType,groupRefType.Important Note
Both proposals support the design of scenario using solely restrictions or extensions. Both approaches also require adjustments to child scenarios when parent scenarios are modified (or referenced scenarios, in the case of the previous approach).
Comparison Example (MaturityDate only in scenario B but not Symbol)
Shows how the same result can be achieved with both approaches.
Parent Scenario:
Child Scenario (Previous Proposal):
Child Scenario (Current Proposal):
Additional Notes
Multiple Reference Instances
In our opinion, the
instanceNameattribute may not be necessary and we recommend reconsidering its design, probably in favor of using thenameattribute for the task.The
instanceNameattribute is used, for example, when a field is referenced multiple times in a component, and it is desirable to have a way to differentiate among these references. For example, to allow a scenario to use these recurring fields as anchor points.We recommend that this attribute be deprecated, and instead one overriding the existing
nameattribute for recurring fields be used in its place. This should be possible because the name attribute is not actually part of an element key, which is composed ofelement type+element id+element scenario id.Notes on Elements Sorting
Here we explain another possible approach that we do not recommend. This section can be skipped.
A similar solution to address the sorting of element could have been to add a new sorting attribute to the
fieldRefType,componentRefType, andgroupRefTypeentities. Similarly to the existingsortinteger property incodeType, we could introduce an attribute to these types to sort newly added elements. When adding new elements to a Child Scenario, this attribute would indicate where the new element is placed in the Parent Scenario by indicating a sort order.Example
In the example below we show how elements in the parent scenario use widely spaced sort numbers to allow the insertion of new elements by child scenario.
If absent, the element’s
sortvalue would be set to the last element in the parent scenario. Using the samesortvalue of an existing element in the parent scenario would result in the new element appearing immediately after it, potentially restricting placement options in subsequent scenario layers.However, we feel that this approach is rigid because it requires planning of sort numbers in the parent scenario, and therefore we do not recommend it.
Beta Was this translation helpful? Give feedback.
All reactions