You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It is not uncommon within internal messaging to use arbitrary bulletin heading data type designators, that are intentionally unstandard to distinguish from standard data type designators used in external messaging.
The DataTypeDesignatorT1 enum should be made an interface like DataTypeDesignatorT2, renaming the enum e.g. StandardDataTypeDesignatorT1. Immutable classes for non-standard data type designators T1 and T2 (e.g. CustomDataTypeDesignatorT1 and CustomDataTypeDesignatorT2) should be created. Equality of objects should be specific to implementing class.
The parser should attempt to parse a standard data type designators, and if it fails to do so, then attempt to parse as non-standard data type designators. Combination of standard and non-standard T1 and T2 should not be prohibited, but if either of T1 or T2 is non-standard, the combination of T1 and T2 should be considered non-standard.
To avoid dependencies to different implementations in parsing (or serializing) code, relations between T1 and T2 could be represented within standard DataTypeDesignatorT1 and DataTypeDesignatorT2 objects.
The text was updated successfully, but these errors were encountered:
It is not uncommon within internal messaging to use arbitrary bulletin heading data type designators, that are intentionally unstandard to distinguish from standard data type designators used in external messaging.
The
DataTypeDesignatorT1
enum should be made an interface likeDataTypeDesignatorT2
, renaming the enum e.g.StandardDataTypeDesignatorT1
. Immutable classes for non-standard data type designators T1 and T2 (e.g.CustomDataTypeDesignatorT1
andCustomDataTypeDesignatorT2
) should be created. Equality of objects should be specific to implementing class.The parser should attempt to parse a standard data type designators, and if it fails to do so, then attempt to parse as non-standard data type designators. Combination of standard and non-standard T1 and T2 should not be prohibited, but if either of T1 or T2 is non-standard, the combination of T1 and T2 should be considered non-standard.
To avoid dependencies to different implementations in parsing (or serializing) code, relations between T1 and T2 could be represented within standard DataTypeDesignatorT1 and DataTypeDesignatorT2 objects.
The text was updated successfully, but these errors were encountered: