A few more encoding artifacts for the FIX 5.0 Components document

, ,
1

Imported from previous forum

2

I think the length fields for data fields should be added to the list, like EncodedTextLen for example.

Also MsgType is an artifact of the encoding, in the same way that ApplVerID is. In FIXML you’d presumably use the element name and namespace to unambiguously identify a message type (I’m not into the specifics of FIXML so this might look a bit off center, but I think you’ll understand my intent anyway):

…

and in FAST you’d use the name and namespace of the application type reference for the same purpose:

...

In none of these examples, the MsgType and ApplVerID need to be communicated as an ordinary field. The exact type of the message follows from built-in constructs of the encoding.

/David

3

[ original email was from Steven Grossman - steven.grossman@transacttools.net ]
> I think the length fields for data fields should be added to the list,

like EncodedTextLen for example.

I agree. The appendix at the end of the document is by no means exhaustive. It only lists those fields that had previously been identified by FIXML work.

Also MsgType is an artifact of the encoding, in the same way that
ApplVerID is. In FIXML you’d presumably use the element name and
namespace to unambiguously identify a message type (I’m not into the
specifics of FIXML so this might look a bit off center, but I think
you’ll understand my intent anyway):

…

and in FAST you’d use the name and namespace of the application type
reference for the same purpose:

…

In none of these examples, the MsgType and ApplVerID need to be
communicated as an ordinary field. The exact type of the message follows
from built-in constructs of the encoding.

I agree that MsgType follows the same argument made in the “FIX 5.0 Components” regarding ApplVerID. I want to clarify your statement, though, because MsgType and ApplVerID are different than the length fields that you mention above.

Length fields are not part of the application data model. They have no business semantic whatsoever.

MsgType and ApplVerID are part of the application data model. Business applications need this knowledge to understand business content. The means of communicating MsgType and ApplVerID should be encoding-specific.

To make this more concrete – one should be able to query a FIX Application Message for a field named ‘MsgType’; one should not be able to query that same message for length fields.

Steven