Imported from previous forum
The Global Technical Committee has reviewed and preliminarily approved the FIXatdl 1.1 Specification. The document now enters a public comment period in which public review and feedback is encouraged. Once the Public Comment period closes, the Global Technical Governance Board will meet to review public comments before final approval.
Please post feedback, comments, and questions as replies to this discussion thread.
A link to the proposal can be found at:
http://www.fixprotocol.org/documents/4977/FIXatdl-1.1.zip
The public comment period ends on February 16, 2010.
EnumPair anomaly in Core XSD:
EnumPair_t defines enumID as a string with a pattern (must start with a letter).
However, ListItem_t in Layout defines enumID as an unconstrained string.
But - these enumIDs are supposed to line up, to enable mapping from uiRep in the Control, via enumID, to the wireValue in the parameter definition.
As such, it is possible to define a ListItem_t.enumID that cannot match an EnumPair_t.enumID.
<xs:attribute name="enumID" use="required">
<xs:annotation>
<xs:documentation>The enumeration name that uniquely identifies a particular legal value of the parameter.</xs:documentation>
</xs:annotation>
<xs:simpleType>
<xs:restriction base="xs:string">
<xs:pattern value="[A-Za-z][A-za-z0-9_]{0,255}"/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
Propose - enforce the same pattern on ListItem_t.enumID.
If too late to change the XSD - add a note that implementors of ATDL editors that ListItem_t.enumID should be constrained by pattern to:
<xs:pattern value="[A-Za-z][A-za-z0-9_]{0,255}"/>
From an implementer…
-
TextField_t – establishing a width for this control – you’re correct – you could derive a field width from Parameter/@maxLength. Perhaps you should point this out as being the appropriate way to size text fields? (NB It would be clearer if the definition for maxLength and minLength read “The maximum/minimum allowable length of the parameter in characters.”)
-
Can StrategyPanels contain both controls and other panels?
Actually the answer is in the entry for ‘StrategyPanel’ in the table on page 21: “Container for either groups of parameters or strategyPanels, but not both.” – perhaps the “not both” should be in bold, and also should it rather read “…groups of Controls or StrategyPanels…?
- Bordering on panels – as per the entry for ‘StrategyPanel/@border’ in the table on page 36, the current list is:
• None
• Line
• RaisedEtched
• LoweredEtched
• RaisedBevel
• LoweredBevel
As mentioned, I would argue that this level of detail puts an unnecessary burden on the implementer, and is stepping a little on the toes of the OMS/EMS in terms of presentation/look-and-feel. I think it would be better to stop at None and Line.
I hope this is helpful.
Hi Greg, All:
Greg’s point about the border styles is right on - it doesn’t make sense to be specifying that sort of detail at the ATDL level. As for the text boxes, sizing a text box based on the maximum length of its input target doesn’t always make sense because it is not uncommon for a text field to be visually shorter than the actual maximum length of the variable you’re entering text for.
From an implementer… 1. TextField_t – establishing a width for this
control – you’re correct – you could derive a field width from
Parameter/@maxLength. Perhaps you should point this out as being the
appropriate way to size text fields? (NB It would be clearer if the
definition for maxLength and minLength read “The maximum/minimum
allowable length of the parameter in characters.”)
Can StrategyPanels contain both controls and other panels?Actually the answer is in the entry for ‘StrategyPanel’ in the table on
page 21: “Container for either groups of parameters or strategyPanels,
but not both.” – perhaps the “not both” should be in bold, and also
should it rather read “…groups of Controls or StrategyPanels…?
Bordering on panels – as per the entry for ‘StrategyPanel/@border’ in the table on page 36, the current list is:• None • Line • RaisedEtched • LoweredEtched • RaisedBevel •
LoweredBevelAs mentioned, I would argue that this level of detail puts an
unnecessary burden on the implementer, and is stepping a little on the
toes of the OMS/EMS in terms of presentation/look-and-feel. I think it
would be better to stop at None and Line.I hope this is helpful.
Discrepancy: Control/@initFixTag needs fix tag number vs. Edit/@field expecting “FIX_” + FIXFieldName
FIXatdl 1.1 spec defines Edit/@field:
When referring to a standard FIX tag then the name must be pre-pended with the string “FIX_”, e.g. “FIX_OrderQty”.
but defines Control/@initFixTag (pos int):
Indicates the initialization value is to be taken from this standard FIX tag.
I think Control/@inifFixTag should be replaced with Control/@initFixField and use the same nomenclature as Edit/@field, otherwise the OMS/EMS application will have to supply this ‘input data’ in two forms (eg 38=100000 and FIX_OrderQty=100000).
UTCTimestamp_t should probably simply eliminate “daily___” attributes and make the __Value ones xs:time
FIXatdl 1.1 spec defines the UTCTimstamp_t Parameter type with 2 sets of 3 attributes (in conjunction with its localMktTz for interpreting):
minValue UTCTimestamp
maxValue UTCTimestamp
constValue UTCTimestamp
dailyMinValue time
dailyMaxValue time
dailyConstValue time
The “daily__” ones are there to support expressing “HH:MM:SS” with the app supplying the current date for to complete the timestamp. The first three likely would never be used (eg when would you say I want a constant value of Jan 15, 2011 at 4pm, or a max value of Dec 31, 2012 at 10pm). Having both sets makes implementing all of this a pain (from experience).
In addition, the Clock control’s initValue is a xs:time (“Daily”), thus there is an inconsistency between Clock/@initValue and UTCTimestamp/@constValue.
I see no reason to keep const, min, and max as full timestamps, and thus the divergence with the daily ones is confusing. My recommendation is to do away with the 3 daily ones and change the type of minValue, maxValue, and constValue to be xs:time.
LocalMktTz_t really needs a way to instruct the FIXatdl rendering application to use the timezone of the market of the security the order is for, eg “{MARKET_TZ}”
Presently, UTCTimestamp_t parameter and Clock_t control have a localMktTz attribute that specifies the name of the timezone (eg “America/New_York”) for which the time-centric attributes are based upon.
For example (Parameter/@dailyMinValue):
<lay:Control ID=“c_ClockNYDailyMax” xsi:type=“lay:Clock_t” label=“Clock (dailyMax 17:30 NY)” parameterRef=“ClockNYDailyMax”/>
For example (Control/@initValue):
<lay:Control ID=“c_ClockNYInit_Daily” xsi:type=“lay:Clock_t” initValue=“07:30:00” localMktTz=“America/New_York” label=“Clock (init 07:30 NY daily)” parameterRef=“ClockNYInit_Daily”/>
The real problem comes in with the fact that the Parameter and Control are tied to a specific Strategy. And while one can have multiple strategies for different regions (eg “TWAP (US)”, “TWAP (EU)”, “TWAP (A/P)”), the Parameter and Control values reflect a single localMktTz. Thus, while “TWAP (US)” might be able to get by with using “America/New_York” and expressing min/max or init times in Eastern Standard Time, this certainly would not work well for “TWAP (A/P)” where Asia/Pac might be dealing with 20 or more markets across 6 or more timezones (and you obviously do not want to repeat strategy definitions for each country). For instance:
dailyMinValue=“07:30:00” localMktTz="Asia/Hong_Kong"
could not be used for an Indian or Australian security.
My suggestion is to add a special token (eg “{MARKET_TZ}”) to the atdl-timezones-1.1.xsd file’s list of valid enums that FIXatdl implementations could interpret as an instruction to attempt to use the timezone of market of the security the order is for. This is somewhat similar to the fact that FIXatdl implementations have to support the special “{NULL}” token. Also the FIXatdl renderer already has to support receiving ‘input data’ from the OMS/EMS to support Strategy filtering (via its Regions, Markets, and SecurityTypes elements), in addition to FIX standard field values used by Edit/@value rules, so one more piece of input data seems doable.
(if not, I greatly question the benefit and relevance of the min, max, init, and const values for these)
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.
RadioButtonList_t and CheckBoxList_t need ability to express the “orientation” (vertical or horizontal) of its buttons/checkboxes
Presently the FIXatdl rendering application does not know whether the FIXatdl XML file author intends to have a series of radio buttons or checkboxes laid out horizontally or vertically. I think we need an “orientation” attribute (same as StrategyPanel/@orientation) added to RadioButtonList_t and CheckBoxList_t (and to choose a ‘default’ presumably horizontal).