[This message was posted by Richard Labs of CL&B Capital Management, LLC
<[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/71039892 - PLEASE DO NOT REPLY BY MAIL.]
> (Don't know if this is the proper place to post comments about an
> unratified spec, but guess someone has to be the first...)
this is a great spot to post - hits a wide audience.
I'll do an overview response, subject to better clarifications by others
(especially cancel/replace....)
> The latest (draft 8) spec contains the following definition for
> Parameter/@revertOnCxlRpl:
>
> "Indicates how to interpret those tags that were populated in an
> original order but are not populated in a subsequent cancel/replace of
> the order message. If this value is true then revert to the value of the
> original order, otherwise a null value or the parameter’s default value
> is to be used."
>
> Two questions:
>
> 1. By "null value", does this mean omit this parameter from the
> cancel/replace message?
Nulls are never sent on the FIX wire.
Up in the GUI however a control can have a Null value. See documentation
searching on "{NULL}" which is used inside FIXatdl merely as a token. When it
comes time to "load up the fields in a FIX message on the wire" any widget
value associated to a parameter containing a {NULL} token is simply discarded
forever and nothing related to it is actually placed in the FIX message on the
wire.
revertOnCxlRpl = True
Here your "cancel/replace" screen ticket would typically not show a widget tied
to that parameter. (or would display it read only) The trader can't change what
was send before, however the target is indicated they explicitly want it sent
again. Of course there is the master exception - if that parameter was {NULL}
before - then don't "send it" again (never send nulls). If however the
parameter was not-Null, then DO send it again, exactly as before. In the
documentation "default" means default to sending again, exactly what was
orginally sent. Yes, reloading prior sent FIXatdl orders as cancel/replace type
follow ups requires the OMS to remember and "look up" what went out before.
Here the Target is saying - you can't rely on our end to look up for you what
you sent us before.
Note:
mutableOnCxlRpl = True implies allowing the trader to potentially enter a new
value on the cancel/replace. This implies there is some possible advantage
(such as not loosing a place in a cue) while still managing to slip in a last
second parameter change - on a best effort basis. (Where there is zero
advantage, a full cancel followed by a full replace is much more straight
forward). Also note - few locations actually allow beneficial use of
mutableOnCslRpl.
If mutableOnCxlRpl = True THEN you should always send a fresh copy of that
parameter (unless its marked optional) even if it has not changed.
Also if mutableOnCxlRpl = True THEN revertOnCxlRpl = False
> 2. I can't seem to find any reference to "default value" for parameters in
> the spec.
In FIXatdl the "FIX Wire" (parameters) are isolated from the GUI
(controls/widgets).
When you put a widget "up" on the screen and hook it up to a parameter "down"
on the wire the widget itself provides the initial value (initValue). Unchanged
by the trader, that initValue of the widget is loaded into the parameter
(becomes the default).
If you want a constant value sent "down" on the wire, but don't want the trader
to change it (or perhaps even see it) you set that as a constValue of the
parameter.
Next you will need to bear with me for a second. Take the prospective of an
FIXatdl xml file author. He wants to declare a parameter called MyMaxBid. So
that starts out easy, step one name it:
<Parameter name=”MyMaxBid”/>
Next we need to force the choice of a datatype for the algo parameter myMaxBid,
and we MUST restrict that to exactly one of the allowable FIX Protocol
datatypes. I.e. the data type must in the set of { Amt | Boolean | char |
Currency | data | Exchange | float | int | Length | LocalMktDate | month-year
| MultipleCharValue | MultipleStringValue | NumInGroup | Percentage | Price |
PriceOffset | Qty | SeqNum | string | UTCDateOnly | UTCTimeOnly | UTCTimestamp }
We do this not by extending the parameter element itself (name=MyMaxBid), nor
by adding attributes.
Parameter just extends Parameter_t. Much more important is that Parameter_t is
marked ABSTRACT.
in the schema file
<xs:complexType name="Parameter_t" abstract="true">
Abstract means data type not set. That means that the data type of Parameter_t
MUST be set in the XML instance document via the xsi:type attribute, (ie not
known in advance in the XSD file) and the type MUST refer to a type we have
defined in the XSD file.
You don't know the entire structure of a parameter until this xsi:type is set
in the xml instance document, then, between the two documents you can determine
the exact structure of that specific parameter.
In the XML file
<Parameter name=”MyMaxBid” xsi:type=”Price_t” />
OK, now we have the linkages; MyMaxBid must have the data type Price_t. We know
Parameter (name=”MyMaxBid”) has a structure of parameter, extending
Parameter_t, and also (via the xsi:type) extending Price_t.
So you need to look at each of the three. Parameter is ridiculously simple,
inherits everything from Parameter_t. Parameter_t picks up all the common
parameter attributes: name, fixTag, use, mutableOnCxlRpl, revertOnCxlRepl,
definedByFix, a text description, and a set of enumeration pairs. You then must
drill down via the xsi:type="Price_t" to see what is inherited from that:
minValue, maxValue, constValue (and yet one more additional inheritance - from
Numeric_t, which adds the attribute precision). Yes, that's a lot of drill
down. Note also that minValue, maxValue, and constValue are all of type Price -
which defined 100% by FIX Protocol (as xs:decimal)
OK that was a very long trip around the barn. We had reasons to do it this way,
one of which was making sure everything we were doing in FIXatdl saluted the
FIX protocol flag 100% down at the wire level. We had to prevent anyone from
inventing a new, unknown datatype that might have caused trouble for any of the
standing FIX infrastructure. Every message leaving a FIXatdl "front end" GUI is
just 100% plain vanilla FIX.
Another area bound to come up - no we didn't spend too much time on Widget
level validation however, yes, you can use parameter min and max to make
individual widgets reject out of bounds input. Everything we did with
validation rules made the simplifying assumption - all values are in and the
trader has pressed send order or validate button. IE batch oriented validation,
at the end of order entry.
Parameter Element Extension
Controls have initValue - is this what is meant, or have
> I missed something?
>
> Thanks in advance - Steve.
>
[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.
