Imported from previous forum
Ocasionally we have counterparties that send us messages with <tag>=<no value> for optional fields.
For Example, here is part of a message:
<SOH>58=<SOH>19=5<SOH>
The FIX 4.0 specification states on page 3 that messages are
"counstructed of a stream of <tag>=<value> fields."
Is 58=<SOH> valid?
Not only does this seem invalid but it eats up bandwith and parsing time(albeit a small amount).
Since optional fields do not have to be added to the body of the message, our interpretation is that if the tag exists and the value does not, a transmission error may have occurred.
[ original email was from Satoru Mizukami - satoru.mizukami@nssmb.com ]
On the talking about Fix4.1J ( Japanese extension ), Members of Technical work group in Japan have reached the same question.
Fix-specification does not say the tags we can not use in the message.
It say the essential or optional tag, so we don’t know whether we can use any other tag on messages.
We decide ( on Fix4.1J specification ) we can not use any tags except essential and optional in the message.
and we do not use empty-tag, it will be estimated Error,
In the case we have to use a tag which is essential and no need to set any value,
we have to set some dummy-value , like space-character or 0 for that purpose.
That is our approach to solve and make sure the work of system…
> Ocasionally we have counterparties that send us messages with <tag>=<no value> for optional fields.
>
> For Example, here is part of a message:
> <SOH>58=<SOH>19=5<SOH>
>
> The FIX 4.0 specification states on page 3 that messages are
> "counstructed of a stream of <tag>=<value> fields."
>
> Is 58=<SOH> valid?
>
> Not only does this seem invalid but it eats up bandwith and parsing time(albeit a small amount).
>
> Since optional fields do not have to be added to the body of the message, our interpretation is that if the tag exists and the value does not, a transmission error may have occurred.
>
Optional fields without values should simply not be specified in the FIX message. A Reject message is the appropriate response to a tag with no value.
> On the talking about Fix4.1J ( Japanese extension ), Members of Technical work group in Japan have reached the same question.
> Fix-specification does not say the tags we can not use in the message.
> It say the essential or optional tag, so we don’t know whether we can use any other tag on messages.
>
> We decide ( on Fix4.1J specification ) we can not use any tags except essential and optional in the message.
> and we do not use empty-tag, it will be estimated Error,
> In the case we have to use a tag which is essential and no need to set any value,
> we have to set some dummy-value , like space-character or 0 for that purpose.
> That is our approach to solve and make sure the work of system…
>
>
> > Ocasionally we have counterparties that send us messages with <tag>=<no value> for optional fields.
> >
> > For Example, here is part of a message:
> > <SOH>58=<SOH>19=5<SOH>
> >
> > The FIX 4.0 specification states on page 3 that messages are
> > “counstructed of a stream of <tag>=<value> fields.”
> >
> > Is 58=<SOH> valid?
> >
> > Not only does this seem invalid but it eats up bandwith and parsing time(albeit a small amount).
> >
> > Since optional fields do not have to be added to the body of the message, our interpretation is that if the tag exists and the value does not, a transmission error may have occurred.
> >
>
[ original email was from Gerard Putter - Gerard.Putter@fincomplus.com ]
In my opinion specifying <SOH>58=<SOH> is different from omitting the tag altogether. I use <SOH>58=<SOH> to send an empty text, which is not the same as sending no text at all. I really don’t see another way to send an empty string. This applies to required as well as optional tags. Of course for a tag with a numeric data type, the construction would always be invalid, even for an optional tag.
> Ocasionally we have counterparties that send us messages with <tag>=<no value> for optional fields.
>
> For Example, here is part of a message:
> <SOH>58=<SOH>19=5<SOH>
>
> The FIX 4.0 specification states on page 3 that messages are
> "counstructed of a stream of <tag>=<value> fields."
>
> Is 58=<SOH> valid?
>
> Not only does this seem invalid but it eats up bandwith and parsing time(albeit a small amount).
>
> Since optional fields do not have to be added to the body of the message, our interpretation is that if the tag exists and the value does not, a transmission error may have occurred.
>
FIX does not have the concept of an "empty string". It is "illegal" (cause for Reject) to send a tag without a value. Optional fields can simply not be specified. Why do you need to send "an empty string" for the Text field? What is your counterparty supposed to infer from that?
> In my opinion specifying <SOH>58=<SOH> is different from omitting the tag altogether. I use <SOH>58=<SOH> to send an empty text, which is not the same as sending no text at all. I really don’t see another way to send an empty string. This applies to required as well as optional tags. Of course for a tag with a numeric data type, the construction would always be invalid, even for an optional tag.
>
> > Ocasionally we have counterparties that send us messages with <tag>=<no value> for optional fields.
> >
> > For Example, here is part of a message:
> > <SOH>58=<SOH>19=5<SOH>
> >
> > The FIX 4.0 specification states on page 3 that messages are
> > “counstructed of a stream of <tag>=<value> fields.”
> >
> > Is 58=<SOH> valid?
> >
> > Not only does this seem invalid but it eats up bandwith and parsing time(albeit a small amount).
> >
> > Since optional fields do not have to be added to the body of the message, our interpretation is that if the tag exists and the value does not, a transmission error may have occurred.
> >
>
If the tag is optional and the sending party does not have a value to offer, why should the tag be sent at all.
> FIX does not have the concept of an “empty string”. It is “illegal” (cause for Reject) to send a tag without a value. Optional fields can simply not be specified. Why do you need to send “an empty string” for the Text field? What is your counterparty supposed to infer from that?
>
>
> > In my opinion specifying <SOH>58=<SOH> is different from omitting the tag altogether. I use <SOH>58=<SOH> to send an empty text, which is not the same as sending no text at all. I really don’t see another way to send an empty string. This applies to required as well as optional tags. Of course for a tag with a numeric data type, the construction would always be invalid, even for an optional tag.
> >
> > > Ocasionally we have counterparties that send us messages with <tag>=<no value> for optional fields.
> > >
> > > For Example, here is part of a message:
> > > <SOH>58=<SOH>19=5<SOH>
> > >
> > > The FIX 4.0 specification states on page 3 that messages are
> > > “counstructed of a stream of <tag>=<value> fields.”
> > >
> > > Is 58=<SOH> valid?
> > >
> > > Not only does this seem invalid but it eats up bandwith and parsing time(albeit a small amount).
> > >
> > > Since optional fields do not have to be added to the body of the message, our interpretation is that if the tag exists and the value does not, a transmission error may have occurred.
> > >
> >
>
Correct. Do not provide tag=<SOH> if you have no value.
Note that in the FIX 4.2 Errata 20010501 we added the following text "All tags must have a value specified. Optional fields without values should simply not be specified in the FIX message. A Reject message is the appropriate response to a tag with no value." to the previous "Each message is constructed of a stream of <tag>=<value> fields with a field delimiter between fields in the stream." statement.
> If the tag is optional and the sending party does not have a value to offer, why should the tag be sent at all.
>
>
> > FIX does not have the concept of an “empty string”. It is “illegal” (cause for Reject) to send a tag without a value. Optional fields can simply not be specified. Why do you need to send “an empty string” for the Text field? What is your counterparty supposed to infer from that?
> >
> >
> > > In my opinion specifying <SOH>58=<SOH> is different from omitting the tag altogether. I use <SOH>58=<SOH> to send an empty text, which is not the same as sending no text at all. I really don’t see another way to send an empty string. This applies to required as well as optional tags. Of course for a tag with a numeric data type, the construction would always be invalid, even for an optional tag.
> > >
> > > > Ocasionally we have counterparties that send us messages with <tag>=<no value> for optional fields.
> > > >
> > > > For Example, here is part of a message:
> > > > <SOH>58=<SOH>19=5<SOH>
> > > >
> > > > The FIX 4.0 specification states on page 3 that messages are
> > > > “counstructed of a stream of <tag>=<value> fields.”
> > > >
> > > > Is 58=<SOH> valid?
> > > >
> > > > Not only does this seem invalid but it eats up bandwith and parsing time(albeit a small amount).
> > > >
> > > > Since optional fields do not have to be added to the body of the message, our interpretation is that if the tag exists and the value does not, a transmission error may have occurred.
> > > >
> > >
> >
>