Imported from previous forum
Hi all,
Hope you guys are doing great!!
Could you please anwser my questions below?
Is it valid to have tags with field value as spaces?
In other words "Is it valid to have a Tag with Field value of spaces ?’
What is a better option, to send tags with field of spaces or not to send the entire tag if it has spaces as field value?
Appreciate your comments in advance!!
Thanks!!
[ original email was from Andrei Goldchleger - agoldchleger@bmf.com.br ]
> Hi all,
Hope you guys are doing great!!
Could you please anwser my questions below?Is it valid to have tags with field value as spaces?
In other words "Is it valid to have a Tag with Field value of spaces ?’What is a better option, to send tags with field of spaces or not to send the entire tag if it has spaces as field value?
String type tags can have spaces, and it is also ok if they are entirely composed of spaces.
Having said that, a ‘blank’ value does not convey much. Thus, if the tag in question is optional, you probably should just omit it.
[ original email was from Aaron Pryce - pryceaaron@gmail.com ]
Hi,
It is worth noting that some implementations do use the ‘space’ character to convey a meaning so might pay to double check with the other side (if the space is being generated by them), they may be doing it for a reason.
rgds
Aaron Pryce
Director
The FIX Consultancy
aaron@thefixconsultancy.com
Hi all,
Hope you guys are doing great!!
Could you please anwser my questions below?Is it valid to have tags with field value as spaces?
In other words "Is it valid to have a Tag with Field value of spaces ?’What is a better option, to send tags with field of spaces or not to send the entire tag if it has spaces as field value?
String type tags can have spaces, and it is also ok if they are entirely composed of spaces.
Having said that, a ‘blank’ value does not convey much. Thus, if the tag in question is optional, you probably should just omit it.
I agree to omit it whenever you want to create a new entity (order, quote, trade) that has an empty string as one of its attributes. However, I would not omit it in case of a modification in general, especially if it currently has a non-empty value. The proper way to “remove” a previous value is by sending spaces.
Vol 4 of the spec says “All of the application-level fields in the original order should be retransmitted with the original values in the Order Cancel/Replace Request, except the fields that are being changed.”.
If the field could have a non-empty value, the receiver will have to initialize it upon entry if the field is omitted. For modification, the receiver should not interpret an omitted field as a request to leave the field unchanged. Others might interpret it to be a request to “remove” the value.
Regards,
Hanno.
Hi all,
Hope you guys are doing great!!
Could you please anwser my questions below?Is it valid to have tags with field value as spaces?
In other words "Is it valid to have a Tag with Field value of spaces ?’What is a better option, to send tags with field of spaces or not to send the entire tag if it has spaces as field value?
String type tags can have spaces, and it is also ok if they are entirely composed of spaces.
Having said that, a ‘blank’ value does not convey much. Thus, if the tag in question is optional, you probably should just omit it.
Thanks for the quick response.
Let me make it clear that this is about the Tag=Field type syntax and optional fields of a message set.
From the FIX spec…“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.”
However my optional fields may contain value sometimes or else contain spaces(empty string) depending on the internal application which is sending it.
Now if the message has to be sent out as FIX 4.4 “Is it valid to have Tag with a field value of spaces(Empty string)?”
In other words “Should the Tag be omited while it has spaces and only be sent in the case where it has a value(Non-empty string)?”
So if the Tag has to be omitted “Will the FIX engine reject it/Is it semantically wrong”?
Thanks.
“A problem well stated is problem half solved” 
I agree to omit it whenever you want to create a new entity (order, quote, trade) that has an empty string as one of its attributes. However, I would not omit it in case of a modification in general, especially if it currently has a non-empty value. The proper way to “remove” a previous value is by sending spaces.
Vol 4 of the spec says “All of the application-level fields in the original order should be retransmitted with the original values in the Order Cancel/Replace Request, except the fields that are being changed.”.
If the field could have a non-empty value, the receiver will have to initialize it upon entry if the field is omitted. For modification, the receiver should not interpret an omitted field as a request to leave the field unchanged. Others might interpret it to be a request to “remove” the value.
Regards,
Hanno.Hi all,
Hope you guys are doing great!!
Could you please anwser my questions below?Is it valid to have tags with field value as spaces?
In other words "Is it valid to have a Tag with Field value of spaces ?’What is a better option, to send tags with field of spaces or not to send the entire tag if it has spaces as field value?
String type tags can have spaces, and it is also ok if they are entirely composed of spaces.
Having said that, a ‘blank’ value does not convey much. Thus, if the tag in question is optional, you probably should just omit it.
The answer is easy if you limit it to the FIX engine. Fields that are optional can be omitted. If they are present in the message then they have not been omitted. One or more spaces between quotation marks is a valid character for data type String. The same is true for optional fields with default values (e.g. TimeInForce=0=Day) which could theoretically be omitted.
The FIX engine should avoid any interpretation beyond the repository which says whether a field is required or not and what kind of data type a field has (valid values). The number of application level fields should not be changed by the FIX engine.
Semantics should be left to the application. The FIX engine ensures the message transport and does syntax checks.
Thanks for the quick response.
Let me make it clear that this is about the Tag=Field type syntax and optional fields of a message set.
From the FIX spec…“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.”
However my optional fields may contain value sometimes or else contain spaces(empty string) depending on the internal application which is sending it.
Now if the message has to be sent out as FIX 4.4 “Is it valid to have Tag with a field value of spaces(Empty string)?”In other words “Should the Tag be omited while it has spaces and only be sent in the case where it has a value(Non-empty string)?”
So if the Tag has to be omitted “Will the FIX engine reject it/Is it semantically wrong”?Thanks.
“A problem well stated is problem half solved”I agree to omit it whenever you want to create a new entity (order, quote, trade) that has an empty string as one of its attributes. However, I would not omit it in case of a modification in general, especially if it currently has a non-empty value. The proper way to “remove” a previous value is by sending spaces.
Vol 4 of the spec says “All of the application-level fields in the original order should be retransmitted with the original values in the Order Cancel/Replace Request, except the fields that are being changed.”.
If the field could have a non-empty value, the receiver will have to initialize it upon entry if the field is omitted. For modification, the receiver should not interpret an omitted field as a request to leave the field unchanged. Others might interpret it to be a request to “remove” the value.
Regards,
Hanno.Hi all,
Hope you guys are doing great!!
Could you please anwser my questions below?Is it valid to have tags with field value as spaces?
In other words "Is it valid to have a Tag with Field value of spaces ?’What is a better option, to send tags with field of spaces or not to send the entire tag if it has spaces as field value?
String type tags can have spaces, and it is also ok if they are entirely composed of spaces.
Having said that, a ‘blank’ value does not convey much. Thus, if the tag in question is optional, you probably should just omit it.
In my experience some FIX engines, on receipt of a message with space-valued tags, will accept the message and simply ignore the tag with the space-values as if it did not exist. Other engines will reject a message of this sort, especially if the field type of the space-filled tag is anything but string or char.
You would be practicing good FIX-citizenry if you would omit space-valued tags which conveyed no information. If however, if you felt you must send it (think of Hanno’s cancel-replace example where you wish to “remove” a previous value), you could do so because a space, technically, is a value and meets the requirement that “All tags must have a value specified”.
Be careful, though. It would be wise to test these scenarios with your target systems since their responses may differ.
-Greg
Thanks all for all the valuable thoughts!!
In my experience some FIX engines, on receipt of a message with space-valued tags, will accept the message and simply ignore the tag with the space-values as if it did not exist. Other engines will reject a message of this sort, especially if the field type of the space-filled tag is anything but string or char.
You would be practicing good FIX-citizenry if you would omit space-valued tags which conveyed no information. If however, if you felt you must send it (think of Hanno’s cancel-replace example where you wish to “remove” a previous value), you could do so because a space, technically, is a value and meets the requirement that “All tags must have a value specified”.
Be careful, though. It would be wise to test these scenarios with your target systems since their responses may differ.
-Greg