Imported from previous forum
For many years I have been teaching that the following are equivalent and are all illegal in FIX:
“1=”
"1= "
"1= "
"1= "
It appears that the subject is being raised in the context of “clearing out field values”.
Is there a consensus opinion on how to treat blank strings within FIX fields?
For many years I have been teaching that the following are equivalent and are all illegal in FIX:
“1=”
"1= "
"1= "
"1= "It appears that the subject is being raised in the context of “clearing out field values”.
Is there a consensus opinion on how to treat blank strings within FIX fields?
I thought the protocol allows one or more blanks but a null value is rejected with a session level reject.
[ original email was from Andrei Goldchleger - agoldchleger@bmf.com.br ]
> > For many years I have been teaching that the following are equivalent and are all illegal in FIX:
“1=”
"1= "
"1= "
"1= "It appears that the subject is being raised in the context of “clearing out field values”.
Is there a consensus opinion on how to treat blank strings within FIX fields?
I thought the protocol allows one or more blanks but a null value is rejected with a session level reject.
Agreed. An empty string value is illegal but a value entirely composed of blanks is valid. If a blank account is invalid in the business scenario, this should probably be an application level reject (e.g. Execution Report, Order Cancel Reject, etc).
For many years I have been teaching that the following are equivalent and are all illegal in FIX:
“1=”
"1= "
"1= "
"1= "It appears that the subject is being raised in the context of “clearing out field values”.
Is there a consensus opinion on how to treat blank strings within FIX fields?
Hi Jim,
What do you mean by “clearing out field values” - do you mean someone sends a first message, with certain fields set, then sends a follow-on message with some of the same fields set blank to indicate they want to clear those previous values out from some context related to the first message?
I thought that “1=” is the only illegal scenario here. Actual blanks are allowed elsewhere, at least when accompanied by some “actual” characters, for example “55=BMW GY”. Therefore, should not a string of blanks also be allowed?
For many years I have been teaching that the following are equivalent and are all illegal in FIX:
“1=”
"1= "
"1= "
"1= "It appears that the subject is being raised in the context of “clearing out field values”.
Is there a consensus opinion on how to treat blank strings within FIX fields?
It’s common for underlying code to normalize transmission data before processing, i.e. removing leading and trailing white space and sometimes compressing multiple embedded spaces to a single space. After normalization all of Jim’s examples result in “1=” which is illegal.
I thought that “1=” is the only illegal scenario here. Actual blanks are allowed elsewhere, at least when accompanied by some “actual” characters, for example “55=BMW GY”. Therefore, should not a string of blanks also be allowed?
For many years I have been teaching that the following are equivalent and are all illegal in FIX:
“1=”
"1= "
"1= "
"1= "It appears that the subject is being raised in the context of “clearing out field values”.
Is there a consensus opinion on how to treat blank strings within FIX fields?
I don’t think it is common (or desirable) for FIX engines to mess about with field values - eg stripping out whitespace. CameronFIX, for one, would certainly never modify field values in any way (unless the original value can be reconstructed at the receiving end).
My understanding is that “1=” is the only illegal scenario here and I believe that is the way it should be.
It’s common for underlying code to normalize transmission data before processing, i.e. removing leading and trailing white space and sometimes compressing multiple embedded spaces to a single space. After normalization all of Jim’s examples result in “1=” which is illegal.
I thought that “1=” is the only illegal scenario here. Actual blanks are allowed elsewhere, at least when accompanied by some “actual” characters, for example “55=BMW GY”. Therefore, should not a string of blanks also be allowed?
For many years I have been teaching that the following are equivalent and are all illegal in FIX:
“1=”
"1= "
"1= "
"1= "It appears that the subject is being raised in the context of “clearing out field values”.
Is there a consensus opinion on how to treat blank strings within FIX fields?
Thanks John, but I wasn’t referring to the FIX engine itself but to the app layers that would handle the messages above the engine. There the corruptions of “1=” should still boil down to “1=”.
I don’t think it is common (or desirable) for FIX engines to mess about with field values - eg stripping out whitespace. CameronFIX, for one, would certainly never modify field values in any way (unless the original value can be reconstructed at the receiving end).
My understanding is that “1=” is the only illegal scenario here and I believe that is the way it should be.
It’s common for underlying code to normalize transmission data before processing, i.e. removing leading and trailing white space and sometimes compressing multiple embedded spaces to a single space. After normalization all of Jim’s examples result in “1=” which is illegal.
I thought that “1=” is the only illegal scenario here. Actual blanks are allowed elsewhere, at least when accompanied by some “actual” characters, for example “55=BMW GY”. Therefore, should not a string of blanks also be allowed?
For many years I have been teaching that the following are equivalent and are all illegal in FIX:
“1=”
"1= "
"1= "
"1= "It appears that the subject is being raised in the context of “clearing out field values”.
Is there a consensus opinion on how to treat blank strings within FIX fields?
For many years I have been teaching that the following are equivalent and are all illegal in FIX:
“1=”
"1= "
"1= "
"1= "It appears that the subject is being raised in the context of “clearing out field values”.
Is there a consensus opinion on how to treat blank strings within FIX fields?
Can’t they just do this by excluding the field entirely on subsequent messages? If they aren’t going to use a custom message or other proprietary mechanism to do this, it seems that it might make sense to just use the exclusion of the field as the indication that the field needs to be reset…
For many years I have been teaching that the following are equivalent and are all illegal in FIX:
“1=”
"1= "
"1= "
"1= "It appears that the subject is being raised in the context of “clearing out field values”.
Is there a consensus opinion on how to treat blank strings within FIX fields?
Can’t they just do this by excluding the field entirely on subsequent messages? If they aren’t going to use a custom message or other proprietary mechanism to do this, it seems that it might make sense to just use the exclusion of the field as the indication that the field needs to be reset…
The implementation in question wants clients to submit edits of previously submitted trades with only the fields that are to change - not full trades marked “replace” with changes in place. So if the original trade had 1=ACCOUNT the client needs a way to indicate “erase tag 1=”.
[ original email was from Andrei Goldchleger - agoldchleger@bvmf.com.br ]
> > > For many years I have been teaching that the following are equivalent and are all illegal in FIX:
“1=”
"1= "
"1= "
"1= "It appears that the subject is being raised in the context of “clearing out field values”.
Is there a consensus opinion on how to treat blank strings within FIX fields?
Can’t they just do this by excluding the field entirely on subsequent messages? If they aren’t going to use a custom message or other proprietary mechanism to do this, it seems that it might make sense to just use the exclusion of the field as the indication that the field needs to be reset…
The implementation in question wants clients to submit edits of previously submitted trades with only the fields that are to change - not full trades marked “replace” with changes in place. So if the original trade had 1=ACCOUNT the client needs a way to indicate “erase tag 1=”.
I see. We had a similar issue in our order entry systems. As we were already using AccountType in conjunction with Account, we defined a custom AccountType value to indicate the account removal.
Non standard, I know, but there is no standardized mechanism for field removal on edits.
For many years I have been teaching that the following are equivalent and are all illegal in FIX:
“1=”
"1= "
"1= "
"1= "It appears that the subject is being raised in the context of “clearing out field values”.
Is there a consensus opinion on how to treat blank strings within FIX fields?
Can’t they just do this by excluding the field entirely on subsequent messages? If they aren’t going to use a custom message or other proprietary mechanism to do this, it seems that it might make sense to just use the exclusion of the field as the indication that the field needs to be reset…
The implementation in question wants clients to submit edits of previously submitted trades with only the fields that are to change - not full trades marked “replace” with changes in place. So if the original trade had 1=ACCOUNT the client needs a way to indicate “erase tag 1=”.
Ah, I see. Even if you were sending blank fields to indicate an erase type instruction, wouldn’t you still have a problem with numeric fields - price, quantity, and so on? If the underlying FIX engine is doing any kind of validation against a ‘normal’ FIX data dictionary, what would it be expected to do if it received an integer field that only contained whitespace characters?
Thanks,
Russ
For many years I have been teaching that the following are equivalent and are all illegal in FIX:
“1=”
"1= "
"1= "
"1= "It appears that the subject is being raised in the context of “clearing out field values”.
Is there a consensus opinion on how to treat blank strings within FIX fields?
Can’t they just do this by excluding the field entirely on subsequent messages? If they aren’t going to use a custom message or other proprietary mechanism to do this, it seems that it might make sense to just use the exclusion of the field as the indication that the field needs to be reset…
The implementation in question wants clients to submit edits of previously submitted trades with only the fields that are to change - not full trades marked “replace” with changes in place. So if the original trade had 1=ACCOUNT the client needs a way to indicate “erase tag 1=”.
Ah, I see. Even if you were sending blank fields to indicate an erase type instruction, wouldn’t you still have a problem with numeric fields - price, quantity, and so on? If the underlying FIX engine is doing any kind of validation against a ‘normal’ FIX data dictionary, what would it be expected to do if it received an integer field that only contained whitespace characters?
Thanks,
Russ
Numeric fields are not a problem - zero serves to erase a non-zero value in this implementation. fields are the problem since an empty (or all-blank) tag or attribute (FIXML) seems to be invalid.
Ideally the message with a blank field is wrong. Some fix engines do disconnect on facing these type of messages.