[This message was posted by Richard Labs of CL&B Capital Management, LLC
<r...@clbcm.com> 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/ce113965 - PLEASE DO NOT REPLY BY MAIL.]
>Are there any docs available? The Spec draft doc still refers to the old
>release.
New docs are on the agenda however for right now all we have are the prior
version docs plus the in-line documentation. XMLspy can also spin out 277 pages
of documentation on the existing schema. Some operations have successfully
coded parsers based on what’s currently available but all agree additional
final documentation will be very welcome.
See also in CORE the change log.
>Specifically, at the moment, I'm unclear about the relationship between
>Parameter_t and Control_t.
During the last refactoring the WG did all it could to take a
Model/View/Controller like approach and isolate those areas. Roughly this
equates to the four interleaved schema:
CORE – roughly the data model for the algo and specifically how all that looks
on a standard FIX wire. We refer to this as the “data contract” – at the end of
the day an algo order must look like this on the FIX wire in standard FIX
TAG=Value format (except in the very rare instance that someone is using XML
syntax FIX messaging, which is also supported.) The primary thing the CORE
schema deals with are algo parameters.
VALIDATION – batch validation after the trader is done filling out 100% of the
order and hitting the “send order” button. Has NOTHING to do with field by
field validation. Roughly equates to model (database rules that fire to
maintain an iron fist over data integrity)
FLOW – sort for Work Flow – the process starting at time zero and ending with
pressing send order button whereby the trader interacts with the GUI to prepare
an order. Can involve appearing and disappearing panels, implies some at least
a rudimentary event model, can branch, etc. Uses rule that are constructed
similar to Validation. Is nowhere near as rich as a full feature GUI – pretty
much only the “basics”. Roughly equivalent to a GUI Controller.
LAYOUT – roughly the “View”. I.e. the look the algo order ticket takes on the
screen. Note here the FIXatdl standard from day one recognized the specific
trader GUI to be the oftentimes highly evolved, highly proprietary, intensely
defended intellectual property of a specific OMS vendor. One OMS vendor summed
it up best (reflecting virtually every OMS vendor’s opinion) “It will be a cold
day in hell when I let a BD directly draw their order ticket on my OMS.” For
this and other business reasons (like going from dumb terminals, hand helds,
and every conceivable software environment (Java, C#, C++, Ajax, Flash, Perl,
3270, HTML…) the LAYOUT information contained in FIXatdl files is optional,
loose and virtually generic. Some OMS vendors and systems will 100% ignore all
BD “suggestions” contained in the LAYOUT area of the xml files.
On the other hand many thought the industry should have the ability to indeed
automatically generate exact algo order entry screens on the fly. OMS vendors
can therefore use the supplied, generic LAYOUT information as they see fit,
including overriding and extending that information. The primary things the
Layout schema deals with are strategyLayout (0-1) per algo, roughly equivalent
to the entire “order ticket”, which in turn, contains strategyPanel (1 to many,
including nesting), which in thrun, contain controls (0 to many). Controls are
the generic screen widgets. The FIXatdl specification specifically enumerates a
highly generic set of these as a library of allowable FIXatdl controls. The
FIXadl xml file author is therefore limited to that hightly specified set. The
OMS file consumer however is free to ignore that information, over ride it, or
extend it in any way they sees fit. They still “own” the GUI.
When parsing up a FIXatdl xml file and building a screen for a specific algo
strategy you read the file for panels and controls and use that information
first (as desired) to help draw and position GUI controls on the screen.
Note, there can be GUI Controls on the screen that are only used during the
order build process and do not have a corresponding parameter going on a FIX
wire. We call these controls “Helper Controls” – they need to be rendered but
their values never end up on the FIX wire. There are other controls like labels
that can be used to display pre trade feedback information that has nothing to
do with a parameter on the wire.
The “Helper Controls” can also be used in some very “responsive” ways with the
FLOW schema. (see below.)
There is no guarantee your FIXatdl xml file will even have author provided
GUI/LAYOUT information (although we would hope it would). In rendering the
order ticket you always start by reading for the LAYOUT information, if
available. Then, the OMS system can then use it directly, map it, override it,
extend it, etc. If its not available, you are forced to make all your own
LAYOUT decisions. Most will opt here to look at parameters and their specific
data types and dumping those all on the screen in the order presented in the
file, choosing a default control/GUI widget based on the parameter data type.
Couple other notes for OMS GUI designers:
1. Might want to consider the use-case we call “Single buy-side genius trader
with several other junior traders”. Here a complex algo with say 10 parameters
is well understood by a single buy-side trader. He wants all the trader
reporting to him to use the algo, but he wants to pre-set 7 of the algo
parameters for them in a locked mode, allowing the JR traders to only enter the
remaining 3 parameters. He creates an order template with the preset parameters
and saves that as a FIXatdl file. The JR traders then only use that subsequent
FIXatdl file for their trading.
2. Always review cancel/replace. Some algo strategies allow a subsequent
message (0 to many) to be sent after the first NewOrder message goes out. That
subsequent message changes in-process parameters without knocking the original
order out (for example, changing a parameter without knocking out the time
priority established by the original order.)
The functionality to retrieve the prior sent order is outside the scope of
FIXatdl however we do specify which parameters are mutable on cancle/replace.
The OMS should retrieve the prior order, then adjust the GUI so ONLY the
mutable on cancel/replace parameters are editable by the trader. Then send out
the cancel/replace.
3. With FLOW (see below) you can get into some very complex order build
sequences including branching, panels appearing and disappearing, etc. In the
event of trouble you probably want a “flight recorder” style logging system
that has the capability to take snapshots of state for later use in decomposing
trader / system interactions.
4. Controls with Enumerations map to Parameters with Enumerations on a one to
one basis. However the GUI user interface language elements are all
localizable. This is perhaps best illustrated by an example:
<lay:Control ID="ctlAgencyOnly" xsi:type="lay:DropDownList_t" label="Agency
Only?" initValue="Yes" parameterRef="paramAgencyOnly"/>
<lay:ListItem enumID="Yes" uiRep="Sí"/>
<lay:ListItem enumID="No" uiRep="No"/>
</lay:Control>
<Parameter name="paramAgencyOnly" xsi:type="Int_t" fixTag="81" use="required">
<EnumPair wireValue="1" enumID="Yes"/>
<EnumPair wireValue="0" enumID="No"/>
</Parameter>
There is a “three step” process getting the enumerated value of a control on to
an enumerated value on the FIX wire.
Assume the user has selected “Sí” via the GUI.
1. Extract from the control either the index number, or the value “Si”
2. Translate that output value locally to the value “Yes”. Carry that
“Yes” output down for use in the FIX data contract area (i.e. the CORE
parameter level
3. Look up “Yes” at the Parameter level. Note that maps to a “1”. Put 1 on
the FIX wire.
>It used to be that Parameters and StrategyPanels were mutually exclusive. But
>that's not the case anymore. So, if both are present, how should they be
>handled, given that Control_t.parameterRef is optional? (I see that a group of
>Parameters with no layout still validates).
See above, including the use-case of XML author did not any add any LAYOUT info
(O.K. it’s pretty horsy, but infer the controls from the parameter data types
and just thrown it all up on the screen in the order the parameters are listed
in the file.)
See Helper Control above (i.e. a control only used for GUI / work flow purposes
– does not result in any data going on the FIX wire.
In the GUI area it goes:
StrategyLayout – analogous to the entire order “ticket” total container
StrategyPanel – any grouping of controls, may be nested
Controls – “generic” widgets out of a conceptual standard library
Control_t.parameterRef – optional (if missing the control is for GUI
only) if included you need to eventually take the value out of the control and
carry it down to that parameter “on the wire”.
>Also, the relationship between Control_t and Parameter_t via parameterRef is
>a tad confusing. It seems an extra level has been introduced to convert
>selected value of ListItem back to enumID which has me confused.
See above. Had to do it that way to isolate GUI from data contract. One
advantage is all the “internal structure” of the xml may be in one base
language (perhaps English) and all the GUI language elements may be in a local
language. Concept was always one xml file a SINGLE UI local language. To knock
out multiple, local languages just change the text that hits the screen. In any
case, the resulting FIX message remains identical across different local
language versions.
There were also other technical reasons for isolating the data contract from
the GUI having to do with future versions.
>From prior versions' parameter_t.controlType, I can create a display widget
>from Parameter_t.Type (UTCTimeStamp_t etc.) Why is this info duplicated for
>Control_t.Type (Clock_t etc)?
The OMS only uses the parameter data type in the (hopefully rare) instance that
the XML author leaves out the LAYOUT information. They then have to infer what
control/widget to use from the parameter data type.
Info is not duplicated. Control/widget is specified (out of the very limited
and finite conceptual widget library) in the Control_t.Type area.
Note: in FIXatdl there is no such thing as a custom data type on the FIXwire.
In the wire you only get to use what is already in the FIX spec. (You can still
“abuse” the FIX spec a bit, as you can now. For instance, using a string field
where a more restrictive FIX data type would have been more appropriate.
Enforcement is in FIXatdl was never torqued down tighter than how FIX was
already being implemented out “in the real world”. We were not too “strict” in
our XSDs to accommodate the occasional real world user who was a bit fast and
loose with the FIX spec all along.
>In SampleStrategiesFor-v1.1.xml Tazer strategy, "DisplayQtyField", how is
>wireValue determined?
See above example. Note we have several typos in the sample file around this
area. Will clean that up very soon. The sample file included was really
something we were using to work out some FLOW items. Sorry for any confusion!
>> First off know that we did quite a bit during the last refactoring to
>> isolate the "data contract" (ie the FIX message on the wire) from
>> everything having to do with the GUI.
>Yes, that is evident and to be clear, I do like most of the changes. I wanted
>to understand the need for changes before blindly implementing it on my side
>as I already have a functional app against v2.4.9.
You will see immediate benefits to the newest version after getting used to the
extra step we had to introduce to get the desired isolation. We are convinced
that isolation pays immediate returns and will continue to pay additional
dividends for a long time to come.
> More formal documentation is also in the works.
>
> I can be much more helpful to you on Monday when I'm back inside
> "civilization"...
>I appreciate your input and look forward to your detailed reply on Mon. I do
>have XmlSpy and have been going through the comments in xsd. Unfortunately,
>in some cases, the comment only mentions that an element was removed, not
>necessarily the "why"? :-)
Totally understand the documentation is not in great shape and is unfortunately
“harsh” on the uninitiated. Will eventually get it in great shape but hopefully
you can be productive in most areas right now without holding up for that.
>1) RepeatingGroups - obviously they are mutually exclusive to strategyLayout.
>As the inner element is Parameter_t, how are the minSize/maxSize attributes
>supposed to work? And since Parameters can be present within Strategies, what
>is the business case repeatingGroup is attempting to solve (since this is a
>new element)?
Repeating Groups was a very tricky area we addressed a while ago. It has to do
with order tickets where you don’t know at XML author time exactly how many
securities are contained in the list or how many securities are ultimately
involved in a multi leg. This is an area “fraught with danger” that we hope
most will be able to ignore and avoid.
Basically we were creating the ability for the GUI to present an order ticket
that could take an arbitrary length list. Then have the entire list have
default parameters for each “row” or security, with the ability to go in and
spot over ride any parameter, on any row.
For use-cases we were working with 8 pack and 16 pack orders in fixed income
(8-16) treasury bonds at various maturity dates against a base interest rate
futures contract, etc. Our WG did everything to build use cases in this area
and examine the various ways people were currently sending this type of complex
security order. Bottom line – we did the best we could here for a v1.# level
release and moved on w/o a huge amount of testing and refinement. We think we
have great set of entry level features here but stuff gets very, very exotic
quickly and the last thing we wanted was direct conflict or too much overlap
with Financial Products Markup Language for the truly one-off and similar
esoteric stuff.
>Mapping optional parameterRef back to a parameter, as stated above, and how to
>handle wireValue conversions (along with the DisplayQty example in xml where
>the parameter doesn't specify a wireValue). Your response helped but I'm still
>not seeing the need for duplicating attributes and how to cross-ref back from
>Control when the parameterRef is an optional attribute. For example, if
>parameter is the wire representation and contains type, use, min and maxValue
>attributes (like in EndTime field), why duplicate the same info at the Control
>level? Why not just specify parameterRef back to the parameter and pick up the
>remaining definition from there?
You are into another “hairy” area we had involving validation. You need to know
that ALL validation contained in the VALIDATION schema is intended ONLY to run
against an order that has been 100% filled out by the trader and runs
immediately AFTER he presses the “send order” button. It’s a “batch” style
validation at the “end of the line”.
All the interaction of trader with GUI ahead of the “send order” button press
we call “Work Flow” and have shortened to just FLOW. FLOW can be made to work
on field by field validation as things are filled out. Likewise some validation
concepts can be implemented at the control/widget level. However we do no “hard
wiring” here in the FIXatdl
standard. The “iron fist” is at the “data on the FIX wire” level via the batch
level final validation expressed as rules contained in the VALIDITION area.
One Use-case we discussed endlessly, at multiple point along the way, was the
need to present a control with 0-100 (for percent) that had to put on the wire
as .01, .02, .03 … 1.0. You could validate at the CONTROL/WIDGET level at any
point during order build (using 1,2,3…100) but at the end of the day the batch
validation, run at the end of the line, would need to test .01,.02,.03…1.0 at
the WIRE level. So again, some need for isolating GUI from “data contract”.
>localMktTz: I'm assuming ATDL is following Olson convention. Not a big deal,
>but shouldn't it be a forward slash instead of backslash? (Americas/New_York
>instead of Americas\New_York)?
This comment brings up two great points! First the FIXatdl tech people are
infinitely capable of error, particularly at this level. Whenever in doubt
don’t struggle, just ask. We have not finished final Q&A. Very much appreciate
getting the errata out. We have a long way to go here.
Next point on this is that you should ALWAYS default to the underlying FIX
spec. FIXatdl never alters data types, FIX enumerations, message structures,
etc. We have had numerous requests to standardize something that really had
nothing to do with FIXatdl “add on” top technology. To the extent that
something is standardizeable at the base FIX specification that’s where it must
be done using that well tread process. We do have identified some areas that
could be improved on – things like time & calendar event specifications, etc.
We like to hear of anything impacting algos that would be smoother with
alterations/additions to the basic FIX field definitions and data types (in
particular) however we would take that all up outside of the FIXatdl
development process.
Sometime in the future, when at least a handful of algo parameters are
sufficiently standard across several brokers we may make batch runs at
standardizing them. For now however we just let algo parameters be custom to
each party.
>Older version of the strategies XML had some incorrect validation rules.
>Example:
<parameter xsi:type="Float_t" name="LimitPrice" uiRep="Limit Price"
mutableOnCxlRpl="true" type="8" fixTag="44" use="optional" precision="4"/>
<val:strategyEdit errorMessage="Limit Price must be greater than zero if
entered.">
<val:edit field="LimitPrice" operator="GT" value="0"/>
</val:strategyEdit>
>While I realize this is a user error, but I was wondering is it possible to
>add validation rules such that logicOperator_t equirement can be made more
>explicit on such bad definitions? Otherwise, everyone will be putting the
>blame on the UI for interpreting an optional field as required.
We have the concept of a null token. You are correct the rule is not well
written. It should be the equivalent of IF NOT NULL test
LimitPrice>0
PS: <Locations> under "OPLX" strategies is causing the validation against the
XSD to fail, but most likely, you're aware of it.
Yep. Typeo. Good catch.
Thanks very much for the detailed comments!
[You can unsubscribe from this discussion group by sending a message to
mailto:unsubscribe+100932...@fixprotocol.org]
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Financial Information eXchange" group.
To post to this group, send email to FIX-Protocol@googlegroups.com
To unsubscribe from this group, send email to
fix-protocol+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/FIX-Protocol?hl=en
-~----------~----~----~----~------~----~------~--~---
