|
5.0 Feedback
< Previous Next >
Re: A few more encoding artifacts for the FIX 5.0 Components document
Steven Grossman / NYSE TransactTools
22 Aug 2007 10:59AM ET> 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):
>
> http://www.fixprotocol.org/ns/fix/FIX.5.0"> ...
>
>
> and in FAST you'd use the name and namespace of the application type
> reference for the same purpose:
>
> > ns="http://www.fixprotocol.org/ns/fix/FIX.5.0"> > name="NewOrderSingle"/> ...
>
> 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
Re: A few more encoding artifacts for the FIX 5.0 Components document
Steven Grossman / NYSE TransactTools 22 Aug 2007 10:59AM ET
|
