# PUBLIC COMMENT PERIOD - FIXatdl 1.1 Specification **URL:** \ **Category:** General Q&A\ **Tags:** general-qa, xid\_165985, imported, fixatdl\ **Created:** [February 9, 2010, 3:53am UTC](https://forum.fixtrading.org/t/public-comment-period-fixatdl-1-1-specification/2253 "2010-02-09T03:53:05Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![fp\_x](https://avatars.discourse-cdn.com/v4/letter/f/9de0a6/32.png) [@fp\_x](https://forum.fixtrading.org/u/fp_x)\ **Post date:** [February 9, 2010, 3:53am UTC](https://forum.fixtrading.org/t/public-comment-period-fixatdl-1-1-specification/2253/1 "2010-02-09T03:53:05Z")
Imported from previous forum ---
**Author:** ![fp\_x](https://avatars.discourse-cdn.com/v4/letter/f/9de0a6/32.png) [@fp\_x](https://forum.fixtrading.org/u/fp_x)\ **Post date:** [February 9, 2010, 3:53am UTC](https://forum.fixtrading.org/t/public-comment-period-fixatdl-1-1-specification/2253/2 "2010-02-09T03:53:05Z")
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](http://www.fixprotocol.org/documents/4977/FIXatdl-1.1.zip) The public comment period ends on February 16, 2010. ---
**Author:** ![gmal\_x](https://avatars.discourse-cdn.com/v4/letter/g/87869e/32.png) [@gmal\_x](https://forum.fixtrading.org/u/gmal_x)\ **Post date:** [February 16, 2010, 2:58pm UTC](https://forum.fixtrading.org/t/public-comment-period-fixatdl-1-1-specification/2253/3 "2010-02-16T14:58:12Z")
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. ``` The enumeration name that uniquely identifies a particular legal value of the parameter. ``` 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: \ ---
**Author:** ![gmal\_x](https://avatars.discourse-cdn.com/v4/letter/g/87869e/32.png) [@gmal\_x](https://forum.fixtrading.org/u/gmal_x)\ **Post date:** [February 16, 2010, 4:07pm UTC](https://forum.fixtrading.org/t/public-comment-period-fixatdl-1-1-specification/2253/4 "2010-02-16T16:07:24Z")
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.”) 2. 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…? 1. 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. ---
**Author:** ![russellcurry\_x](https://avatars.discourse-cdn.com/v4/letter/r/d07c76/32.png) [@russellcurry\_x](https://forum.fixtrading.org/u/russellcurry_x)\ **Post date:** [February 17, 2010, 2:17am UTC](https://forum.fixtrading.org/t/public-comment-period-fixatdl-1-1-specification/2253/5 "2010-02-17T02:17:13Z")
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.”) > > 1. > > ``` > 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…? > > 1. > > ``` > 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. ---
**Author:** ![scott.atwell](https://avatars.discourse-cdn.com/v4/letter/s/51bf81/32.png) [@scott.atwell](https://forum.fixtrading.org/u/scott.atwell)\ **Post date:** [February 16, 2010, 11:35pm UTC](https://forum.fixtrading.org/t/public-comment-period-fixatdl-1-1-specification/2253/6 "2010-02-16T23:35:54Z")
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). ---
**Author:** ![scott.atwell](https://avatars.discourse-cdn.com/v4/letter/s/51bf81/32.png) [@scott.atwell](https://forum.fixtrading.org/u/scott.atwell)\ **Post date:** [February 16, 2010, 11:46pm UTC](https://forum.fixtrading.org/t/public-comment-period-fixatdl-1-1-specification/2253/7 "2010-02-16T23:46:35Z")
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. ---
**Author:** ![scott.atwell](https://avatars.discourse-cdn.com/v4/letter/s/51bf81/32.png) [@scott.atwell](https://forum.fixtrading.org/u/scott.atwell)\ **Post date:** [February 17, 2010, 12:10am UTC](https://forum.fixtrading.org/t/public-comment-period-fixatdl-1-1-specification/2253/8 "2010-02-17T00:10:23Z")
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): \ For example (Control/@initValue): \ 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) ---
**Author:** ![scott.atwell](https://avatars.discourse-cdn.com/v4/letter/s/51bf81/32.png) [@scott.atwell](https://forum.fixtrading.org/u/scott.atwell)\ **Post date:** [February 17, 2010, 12:26am UTC](https://forum.fixtrading.org/t/public-comment-period-fixatdl-1-1-specification/2253/9 "2010-02-17T00:26:24Z")
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. ---
**Author:** ![scott.atwell](https://avatars.discourse-cdn.com/v4/letter/s/51bf81/32.png) [@scott.atwell](https://forum.fixtrading.org/u/scott.atwell)\ **Post date:** [February 17, 2010, 12:38am UTC](https://forum.fixtrading.org/t/public-comment-period-fixatdl-1-1-specification/2253/10 "2010-02-17T00:38:29Z")
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).