Imported from previous forum
I’m using both atdl4j and the Rapid Addition’s ATDL editor to view my atdl files. I’m getting consistent behavior in some cases and inconsistent behavior in others.
Issue #1:
I’ve defined a ‘EndTime’ parameter and the control as follows:
-->
Strategy End Time
<lay:Control xsi:type=“lay:Clock_t” ID=“EndTimeClock” label=“End Time” parameterRef=“EndTime” initPolicy=“UseValue” initValue=“15:00:00” localMktTz=“America/New_York”/>
I always get 23:00:00 in both atdl4j and Rapid Addition’s tool. Am I defining it incorrectly?
If I don’t want to have times defined in ‘Clock’ controls when the ticket is initialized how is that accomplished? It seems like you can only have the current time and the time specified by ‘initValue’. I only want a time passed to me if the user specifies one. Otherwise you get into issues with latency, etc and there is no way to provide defaults or default behavior if values are always passed.
Issue #2:
I’ve defined a parameter ‘Aggressiveness’ that is represented by a drop down. I’ve marked it as ‘optional’. When a parameter is ‘optional’ it’s always been my interpretation that the user should have the option to send a value or to not send a value.
<Parameter name="Aggressiveness" xsi:type="Int_t" fixTag="9612" use="optional">
<EnumPair enumID="e_Low" wireValue="0"/>
<EnumPair enumID="e_Medium" wireValue="1"/>
<EnumPair enumID="e_High" wireValue="2"/>
</Parameter>
The atdl4j tool does not allow a value to not be sent but the Rapid Addition tool has a ‘Not specified’ option. I think Rapid’s implementation is correct. But the issue for me as an ATDL author is how should I specify these type’s of parameters. Since the parameter is optional, the user should be able to remove it if doing a cancel/replace or if they initially selected a value but now want to remove it.
Any thoughts would be appreciated.
Mike
I’m using both atdl4j and the Rapid Addition’s ATDL editor to view my atdl files. I’m getting consistent behavior in some cases and inconsistent behavior in others.
Issue #1:
I’ve defined a ‘EndTime’ parameter and the control as follows:→
Strategy End Time
<lay:Control xsi:type=“lay:Clock_t” ID=“EndTimeClock” label=“End Time” parameterRef=“EndTime” initPolicy=“UseValue” initValue=“15:00:00” localMktTz=“America/New_York”/>
I always get 23:00:00 in both atdl4j and Rapid Addition’s tool. Am I defining it incorrectly?
If I don’t want to have times defined in ‘Clock’ controls when the ticket is initialized how is that accomplished? It seems like you can only have the current time and the time specified by ‘initValue’. I only want a time passed to me if the user specifies one. Otherwise you get into issues with latency, etc and there is no way to provide defaults or default behavior if values are always passed.
Issue #2:
I’ve defined a parameter ‘Aggressiveness’ that is represented by a drop down. I’ve marked it as ‘optional’. When a parameter is ‘optional’ it’s always been my interpretation that the user should have the option to send a value or to not send a value.<Parameter name="Aggressiveness" xsi:type="Int_t" fixTag="9612" use="optional"> <EnumPair enumID="e_Low" wireValue="0"/> <EnumPair enumID="e_Medium" wireValue="1"/> <EnumPair enumID="e_High" wireValue="2"/> </Parameter>The atdl4j tool does not allow a value to not be sent but the Rapid Addition tool has a ‘Not specified’ option. I think Rapid’s implementation is correct. But the issue for me as an ATDL author is how should I specify these type’s of parameters. Since the parameter is optional, the user should be able to remove it if doing a cancel/replace or if they initially selected a value but now want to remove it.
Any thoughts would be appreciated.
Mike,
You should use a ‘Helper’ Control (radio button or checkbox) to control optionality for the Clock control. While the parameter may be declared optional, the FIXatdl 1.1 spec never specified whether (and how) Controls should implement optionality behavior.
Please review http://fixprotocol.org/documents/5414/Implementing%20FIXatdl%20-%20Atwell%20-%20FPL%20Americas%20-%20Teaching%20Stream%2020101021.pptx – and specifically slides 33 (“Common Issue: Clock control’s Parameter is optional”) and 34: “Common Issue: Drop Down List’s parameter is optional”).
Mike
Thanks for the info. I read through the power point a while back, but had forgotten the section on how to deal with these issues.
It seems like it should be stated some where that ‘optional’ parameters should be optional. The control used to display an optional parameter shouldn’t determine whether it’s optional.
While using a radio button or checkbox on the clock parameters provides the ability to control whether a value is sent or not, it does add clutter to the ticket and well as adds layout issues you need to deal with which would go away with the ability to not have a value specified for a Clock.
Mike
I’m using both atdl4j and the Rapid Addition’s ATDL editor to view my atdl files. I’m getting consistent behavior in some cases and inconsistent behavior in others.
Issue #1:
I’ve defined a ‘EndTime’ parameter and the control as follows:→
Strategy End Time
<lay:Control xsi:type=“lay:Clock_t” ID=“EndTimeClock” label=“End Time” parameterRef=“EndTime” initPolicy=“UseValue” initValue=“15:00:00” localMktTz=“America/New_York”/>
I always get 23:00:00 in both atdl4j and Rapid Addition’s tool. Am I defining it incorrectly?
If I don’t want to have times defined in ‘Clock’ controls when the ticket is initialized how is that accomplished? It seems like you can only have the current time and the time specified by ‘initValue’. I only want a time passed to me if the user specifies one. Otherwise you get into issues with latency, etc and there is no way to provide defaults or default behavior if values are always passed.
Issue #2:
I’ve defined a parameter ‘Aggressiveness’ that is represented by a drop down. I’ve marked it as ‘optional’. When a parameter is ‘optional’ it’s always been my interpretation that the user should have the option to send a value or to not send a value.<Parameter name="Aggressiveness" xsi:type="Int_t" fixTag="9612" use="optional"> <EnumPair enumID="e_Low" wireValue="0"/> <EnumPair enumID="e_Medium" wireValue="1"/> <EnumPair enumID="e_High" wireValue="2"/> </Parameter>The atdl4j tool does not allow a value to not be sent but the Rapid Addition tool has a ‘Not specified’ option. I think Rapid’s implementation is correct. But the issue for me as an ATDL author is how should I specify these type’s of parameters. Since the parameter is optional, the user should be able to remove it if doing a cancel/replace or if they initially selected a value but now want to remove it.
Any thoughts would be appreciated.
Mike,
You should use a ‘Helper’ Control (radio button or checkbox) to control optionality for the Clock control. While the parameter may be declared optional, the FIXatdl 1.1 spec never specified whether (and how) Controls should implement optionality behavior.
Please review http://fixprotocol.org/documents/5414/Implementing%20FIXatdl%20-%20Atwell%20-%20FPL%20Americas%20-%20Teaching%20Stream%2020101021.pptx – and specifically slides 33 (“Common Issue: Clock control’s Parameter is optional”) and 34: “Common Issue: Drop Down List’s parameter is optional”).
Mike
Thanks for the info. I read through the power point a while back, but had forgotten the section on how to deal with these issues.
It seems like it should be stated some where that ‘optional’ parameters should be optional. The control used to display an optional parameter shouldn’t determine whether it’s optional.
While using a radio button or checkbox on the clock parameters provides the ability to control whether a value is sent or not, it does add clutter to the ticket and well as adds layout issues you need to deal with which would go away with the ability to not have a value specified for a Clock.
Mike
Lack of specificity for the Clock control has been a problem with FIXatdl 1.1. Improving both documentation as well as needed features is something the Algo Trading Working Group has been focused on this year.
Hi Mike,
You can take a look at this doc http://www.fixprotocol.org/documents/5755/NewFeaturesForClockControl.docx which is found in http://www.fixprotocol.org/working_groups/algowg/documents
to get an idea of what new features we’re considering for the Clock control.
As for optional parameters, here are my thoughts:
We’ve found that some systems have the ability for a control to be ‘not specified’ (as in the Rappid Addition case), while other systems do not (atdl4j). This usually applies to drop-downs, where once you’ve selected a value the control can never go back to being unspecified, or sliders, where the value is always specified. For some rendering systems Clock controls fall into this category.
The problem for atdl is that we don’t know which model the rendering system supports. So we did not attempt to make a distinction. The practice that has emerged is to use a helper control to affect the enabled property of the target control. Yes, it does add to the clutter on the screen, but some algo providers have been OK with that.
We had been toying with the idea of allowing atdl to define controls as being “self-enabling”, where it is assumed that embedded somewhere within the control there is a checkbox used for enabling/disabling. The trick is to find a way to support both rendering models with one atdl instance. So far I’ve found it to be a bit tricky.
-Greg