Syntax for header and trailer inclusion

[donmendelson]

Orchestra could use syntax to specify when headers are applicable. Currently, Repository has StandardHeader and StandardTrailer on every message although they are only used in FIX4/FIXT tag value encoding.

[kleihan]

StandardHeader is also used together with FIXML, albeit in a limited fashion (sender/target/versioning).

[donmendelson]

Agreed, @kleihan , that the syntax should not only inform whether a header is used, but also which header component should be inserted in each use case.

[francescoloconte]

Is this issue still relevant? The definition of messageType in repositoryType.xsd indicates a structure that references components, groups, and fields. A message with a header and trailer would use references to the StandardHeader and StandardTrailer to add them to the correct places in the message (FIX or non-FIX protocols). See image below. Am I missing something? If my comment is correct, this issue could be closed.

[donmendelson]

Message definitions in an Orchestra file are intended to represent semantics, not encoding-specific rules. However, StandardHeader and StandardTrailer are only relevant to FIX tag-value encoding, not to other protocols. On projects where I want to be compliant with FIX semantics, but not with its encodings, I am always writing generators of code and structures that have special cases to either ignore header and trailer or substitute something else for them.

My suggestion is to isolate encoding-specific rules to one place in an Orchestra file. In essence it would say: "In the case of tag-value, insert this header and trailer on every message; in the case of some other encoding, insert this other header..." FIX Latest could have the logic for tag-value and FIXML, for example.

[francescoloconte]

Hi Don, if I could repeat what you say above, but perhaps add few additional details. Let's use OSI-7 for a second.

Orchestra is meant to describe Layer 7, the Application layer (semantic, or Dictionary). However, historically FIX has brought elements from Layer 6, the Presentation layer (or encoding), into the Dictionary, by including tags (which are presentation elements); and elements from Layer 5 (five), the Session layer, into the Dictionary, by including the Header and Trailer (which are session elements). In this sense, Orchestra is carrying this burden from the past.

I agree with your suggestion, i.e. to "isolate encoding-specific rules to one place in an Orchestra file". Let me expand on this idea: isolate information about Session and Presentation.

Presentation:

• Information related to encoding can be "isolated", some at the element level and some at the repository level.

At the element level, a field could have an "encodings" element containing information for different encodings, e.g., FIX and SBE:

At the repository level, the information would be of a different nature:

Session:

• Information related to the session, like the header and trailer, can be indicated in a block equivalent to the example above, but perhaps this information is need only at the repository level for now (as far as I can think of). Here below we specify that if the session is FIXT, header and trailer should be added to every message. There is no session defined for SBE because it does not specify a session.

Small note: it should not have been called FIX"T", for Transport (Layer 4), because it is related to the Session (Layer 5). I think it could have been called FIXS.

With the information above, one could use an Orchestra file to encode messages as FIX tag/value or SBE binary. And send it over FIX session with header and trailer, or any other transport like Kafka (which has its own session, and transport too).

[donmendelson]

@francescoloconte I have to think about the syntax of your proposals, but totally agree with your summary.

We already have mappings for datatypes to various field-level encodings in the mappedDatatype element. We need something equivalent to that at a higher structural level.

[francescoloconte]

@donmendelson thank you for confirming that we may be on the right path here. I only put the syntax together quickly. It was just an example and we will need to design it properly.