[This message was posted by Heiko Bock of optitec consulting <[EMAIL PROTECTED]> to the "FAST Protocol" discussion forum at http://fixprotocol.org/discuss/46. You can reply to it on-line at http://fixprotocol.org/discuss/read/c292c943 - PLEASE DO NOT REPLY BY MAIL.]
Hi David, thank you for reply. Yes, I agree. A nullable type for a mandatory field is not useful, because the null value is never used. That's clear. In respect to my example, the field with the nullable type is used with different presence definitions and without any operator. I have asked my question, because a lot of people tell me massively: - nullable types for mandatory fields are not applicable at all - nullable types for mandatory fields are forbidden - nullable types does not work for mandatory fields - etc, etc ...and I can't derive these opinions from the FAST spec. I think, there is a difference between "not useful" and "not possible". Heiko > Nullability is defined in section 10.4 of the FAST Specification 1.1: > > "10.4 Nullability Each field has a type that has a nullability property. > If a type is nullable, there is a special representation of a NULL > value. When a type is non-nullable, no representation for NULL is > reserved. All nullable types are constructed in such a way that NULL is > represented as a 7-bit entity value where all bits are zero. It is > represented as 0x80 when stop bit encoded. > > Unless explicitly specified, non-nullable representations are used." > > A mandatory field always has a value logically and it wouldn't make > sense to use the notion of NULL in that case. (I say logically because a > value is not always physically present in the stream if for example a > copy operator is in use.) > > /David > > > I am often confronted with the opinion: "Mandatory fields are never > > nullable by definition". > > > > I would like to know, where is this defined? > > > > The FAST Specification defines only a positive list of all cases in > > which nullable types have to be used. There are no information about > > forbidden cases. The FAST Protocol - Transfer Encoding Specification - > > gives some information about the sense of Null values. It also does > > not forbid any combinations of nullable data types and mandatory > > presence. > > > > Are there information that explicitly forbid such combinations? > > > > Reason of question & example: I become aware of a template defintion, > > where a field with a nullable supporting integer type is used > > differently: > > a) optional - no operator > > b) mandatory - no operator > > > > c) is explicitly defined within the FAST specification. It is clear, > > that the type have to support Null Values. > > > > d) is not explicitly defined within the spec. I think, because of the > > presence "mandatory", the transfered values of this field would > > never be a null value. So, is the property of null support really a > > problem in this case??? > > > > What do you think? [You can unsubscribe from this discussion group by sending a message to mailto:[EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Financial Information eXchange" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/FIX-Protocol?hl=en -~----------~----~----~----~------~----~------~--~---
