FIX Orchestra V 1.0 Technical Standard post-release comments

1

Hello @hanno.klein,

Being studying the FIX Orchestra V 1.0 Technical Standard, I’ve noticed some typos and faced some questions. Here they are:

3.7.4 Discriminator fields (typo at the most bottom)
The “ecurityIDSource” is specified in the tag fixr:documentation, should be SecurityID Source.

3.8.2 Presence (a presence option is missing in the list)

The possible values of presence are:
• required—the member MUST always be present in a message.
• optional—the member MAY be present; it may be conditionally required based on a rule.
• forbidden—the member MUST NOT be present.
• ignored—the member MAY be present but is not processed by the receiving party, and thus, no validation is performed on it.
• constant—the field has a constant value.
It looks like the option “conditional” is missing; although, it is clearly specified in the “3.8.2.3 Conditionally required field”:
<fixr:fieldRef id=“99” presence=“conditional”>

3.8.2.3 Conditionally required field (typo in the example)
fixr:whenOrdType ****!= ^Stop</fixr:when>

3.10.2.2 State machines
A state machine example contains the state “Halted” that does not have the incoming transition (not mentioned in the property “target” for all other states). Is it implied?

3.10.3 Flows
The attribute “reliability” does not contain the variant “deliver at-least-once” meaning the duplicates are allowed). Is it implied?

2

An earlier release candidate had “conditional” as a presence, but it was later removed. Conditionally required fields should be expressed as optional, possibly with a rule telling when it is required. The example in section 3.8.2.3 is in error.

You are correct about the state machine example – it should have a transition to Halted.

I see that “at least once” terminology is sometimes used. Is that different in practice from “best effort”? The point is that the service is for uncritical flows or where low latency is more important than tight control.

3

Hello @donaldmendelson,

Thank you for the answer!

Regarding the difference between the reliability options “at least once” and “best effort”:
the “best effort” allows both duplicates and message losses while the “at least once” guarantees that messages will be delivered without losing but possibly more than one times, i.e. duplicates are permissible.