[This message was posted by Steve Wilkinson of Cornerstone Technology Limited
<[email protected]> to the "Algorithmic Trading" discussion
forum at http://fixprotocol.org/discuss/31. You can reply to it on-line at
http://fixprotocol.org/discuss/read/39eed9f0 - PLEASE DO NOT REPLY BY MAIL.]
Scott - thanks for the clarification. I think what you have said makes sense,
and unless there are any gainsayers, I will raise a Jira issue to include this
definition of the behaviour in the errata.
I think it is also worth stating in the spec that FIXatdl publishers should
take care when producing strategy files that contain multiple StateRules
updating a single control, as there is potential for non-deterministic results
if two such StateRules evaluate to true at any time.
> > Looking at StateRules in some more detail, I find that there are some
> > implied constraints which aren't explicit in the spec. I would appreciate
> > others' views on whether my understanding is correct.
> >
> > 1. The spec says that StateRules that change the 'enabled' or 'visible'
> > state of a control have a direct mapping to the state of that StateRule
> > (i.e., if StateRule evaluates to true then enabled and/or visible = true
> > and if StateRule evaluates to false then enabled and/or visible = false).
> > This implies to me that there can only be one StateRule per control that
> > manipulates 'enabled' and one that manipulates 'visible' (although they
> > could be the same one).
> >
> > 2. The spec says that except in the case where '{NULL}' is used, transition
> > of a StateRule (with a 'value' attribute) from false to true updates the
> > value of the control, but not in the reverse direction. This implies to me
> > that there could be more than one StateRule per control updating the
> > 'value' attribute.
> >
> > 3. As a StateRule that uses the '{NULL}' value does affect a control's
> > value when transitioning from true to false as well as from false to true,
> > this seems similar to case 1, and would suggest that only one such
> > StateRule should be allowed per control.
> >
> > So my questions are:
> >
> > a) Are my assumptions about 'enabled' and 'visible' StateRules correct -
> > only one StateRule should be allow for each (per control)?
> >
> > b) As there are obviously boundary cases about multiple 'value' StateRules
> > clashing on a given control, should we introduce a rule to also say that
> > only one 'value' StateRule is allowed per control?
> >
> > My considerations are entirely theoretical - some real world examples of a
> > need to break these rules would help, assuming others disagree. However, I
> > fear for implementation complexity if we don't introduce such constraints.
> >
> > Thanks in advance.
>
> I believe that there should only be a single StateRule controlling 'visible'
> and 'enabled' (and it could be the same one), otherwise you have the
> potential to have conflicting rules 'fighting'. Those are boolean rules and
> evaluating the rule can clearly determine the 'rule evaluated to false' thus
> 'set the control to the opposite state'.
>
> The 'value' StateRule is different as it can represent multiple values. Take
> a TextField as a simple illustration. It can have an unlimited set of
> values. I've seen a real world case where there are radio button controls
> (or a drop down) representing aggressiveness (think Low, Med, High) and a
> TextField for Percent Of Volume with StateRules of if RadioButtonLow then
> value="5", if RadioButtonMed then value="15", if RadioButtonHigh then
> value="25". In this case there would be multiple StateRules with 'value='.
>
> The 'value' StateRule with ="{NULL}" is a more special case. It drives
> whether or not the control should be considered to "have a value". And this,
> in turn, drives whether or not the parameter associated with the control has
> a value and would be populated within the FIX message. Some controls such as
> Clock may always 'appear' on the screen with some value, however, if
> value="{NULL}" is set then it won't be eligible to go on the wire (in this
> case it's also a good idea to set enabled="false" to help the user 'know'
> this).
>
> Thus, no I do not think you can restrict a Control to only one 'value'
> StateRule.
[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.
