are empty values permitted?

, ,
1

Imported from previous forum

2

[ original email was from Dave Howorth - Dave.Howorth@omgroup.com ]
On March 1, Scott Atewll wrote:

‘There is a rule that if a tag is specified, a value must exist (e.g. “58=<SOH>” is cause for rejection). (in a message titled “General Q/A : re: Session Management”)’

I can’t find this rule in the 4.2 spec. Could you give me a reference, please? Or is the implication that it is mandatory to Reject all messages for which any one of the SessionRejectReasons is true? The latter seems unlikely since “as a rule, messages should be forwarded to the trading application for business level rejections whenever possible” and an empty string value needn’t be a catastrophe.

Thanks,
Dave Howorth

3

From the FIX 4.2 spec:

Within the "FIX MESSAGE FORMAT AND DELIVERY" section:

  • "Each message is constructed of a stream of <tag>=<value> fields."
  • "All fields (including those of data type data i.e. SecureData, RawData, SignatureData, XmlData, etc.) in a FIX message are terminated by a delimiter character. The non-printing, ASCII "SOH" (#001), is used for field termination."

Within the "Reject (session-level)" message definition:

  • "SessionRejectReason" table lists "4 = Tag specified without a value"

> On March 1, Scott Atewll wrote:
>
> ‘There is a rule that if a tag is specified, a value must exist (e.g. “58=<SOH>” is cause for rejection). (in a message titled “General Q/A : re: Session Management”)’
>
> I can’t find this rule in the 4.2 spec. Could you give me a reference, please? Or is the implication that it is mandatory to Reject all messages for which any one of the SessionRejectReasons is true? The latter seems unlikely since “as a rule, messages should be forwarded to the trading application for business level rejections whenever possible” and an empty string value needn’t be a catastrophe.
>
> Thanks,
> Dave Howorth
>

4

[ original email was from Dave Howorth - Dave.Howorth@omgroup.com ]
> From the FIX 4.2 spec:
>
> Within the "FIX MESSAGE FORMAT AND DELIVERY"
> section:
> - "Each message is constructed of a stream of
> <tag>=<value> fields."
> - "All fields (including those of data type
> data i.e. SecureData, RawData, SignatureData,
> XmlData, etc.) in a FIX message are terminated
> by a delimiter character. The non-printing,
> ASCII "SOH" (#001), is used for field
> termination."

I have two groups of implementers arguing! :frowning:
And I’m looking for evidence to back one view or the other.

Is there anything that says <value> must be non-empty? For example, an empty string is a valid programming construct in most languages.

> Within the "Reject (session-level)" message
> definition:
> - "SessionRejectReason" table lists "4 = Tag
> specified without a value"

Again, is there anything that says it is mandatory to Reject all messages for which any one of the SessionRejectReasons is true?

Thanks again, Dave

5

[ original email was from Georges Gomes - georges@gomes.com ]
>Again, is there anything that says it is >mandatory to Reject all messages for which any >one of the SessionRejectReasons is true?

Empty value must be rejected by the session level… As writed in the FIX Specification… because an empty string make no sense.

If you are expecting a string, you can treat the empty string as default value. Then, an empty string is simply a non present field.

No value -> No tag
No tag -> No value

I hope I have responded to your question…

6

This was put before the FIX Technical Committee and the Technical Committee concurs that a tag without a value is illegal and should be session-level Rejected. In addition the Technical Committee will more explicitly state this in bold text in an Errata of the spec.

> > From the FIX 4.2 spec:
> >
> > Within the “FIX MESSAGE FORMAT AND DELIVERY”
> > section:
> > - “Each message is constructed of a stream of
> > <tag>=<value> fields.”
> > - “All fields (including those of data type
> > data i.e. SecureData, RawData, SignatureData,
> > XmlData, etc.) in a FIX message are terminated
> > by a delimiter character. The non-printing,
> > ASCII “SOH” (#001), is used for field
> > termination.”
>
> I have two groups of implementers arguing! :frowning:
> And I’m looking for evidence to back one view or the other.
>
> Is there anything that says <value> must be non-empty? For example, an empty string is a valid programming construct in most languages.
>
> > Within the “Reject (session-level)” message
> > definition:
> > - “SessionRejectReason” table lists “4 = Tag
> > specified without a value”
>
> Again, is there anything that says it is mandatory to Reject all messages for which any one of the SessionRejectReasons is true?
>
>
> Thanks again, Dave
>