[This message was posted by Scott Atwell of American Century Investments
<[email protected]> to the "General Q/A" discussion forum at
http://fixprotocol.org/discuss/22. You can reply to it on-line at
http://fixprotocol.org/discuss/read/a3dbf344 - PLEASE DO NOT REPLY BY MAIL.]
Parameter/@const (boolean) is redundant with [extendedParameter]/@constValue
Presently the base type, Parameter, contains a boolean "const" attribute, while
the concrete Parameter type (eg Int_t, Qty_t, String_t, etc) has its own
type-specific "constValue" attribute. The FIXatdl 1.1 documentation currently
states:
Parameter/@const Indicates that the value of the parameter as
specified by Parameter/@constValue must be transmitted over the wire. Const
parameters typically will not have an associated GUI control.
Parameter/@constValue The value of a parameter that is
constant and is not referred by a Control element. This value must be sent on
the wire by the order generating application. Required when:
Parameter/@const=true
Thus, according to the doc, you would have to provide [const="true"
constValue="123"]. Given that constValue is defined in the type which derives
Parameter_t, it would then be possible for Parameter/@const to not be relevant
if a derived type did not support constValue. I'm not sure when one would use
[const="false"].
(there is a special case with UTCTimestamp_t and its "dailyConstValue" in
addition to "constValue", however, I wrote up issues and recommendation to
consolidate into simply "constValue" on a separate post)
It seems that one could simply rely upon Parameter/@constValue being populated
as to whether or not there is a constant value present, and thus
Parameter/@const could be deprecated or eliminated.
[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.
