[This message was posted by David Rosenborg of Pantor Engineering AB <[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/bba0190d - PLEASE DO NOT REPLY BY MAIL.]
In the FAST Specification 1.1, the terms "mandatory" and "optional" refers to concepts in the template definition. So if you create a FAST 1.1 template definition and specifies that a field is mandatory, it must always be encoded in a non-nullable representation or a decoder based on the same template definition wouldn't work. This is as defined in the specification. Your perception of the nullability of a field outside the FAST encoding layer is another thing and there the FAST specification obviously has nothing to say. If you for example treat a field as mandatory in your application but declare the field to be optional in the template, you're free to do so, though I'd try to avoid it. /David > 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 -~----------~----~----~----~------~----~------~--~---
