[This message was posted by Dev Ashish of Lab49 <[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/b8bc95ad -
PLEASE DO NOT REPLY BY MAIL.]
Rick,
> 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.
> 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"? :-)
As I mentioned here, the main issues I'm having is defining proper strategies
as use cases to rebuild and test the UI against. I'll list the items as clearly
as I can below:
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)?
2) 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?
3) 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)?
4) 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.
I think I understand Control_t better now if it's going to be the UI driver. I
may have additional questions later on though.
PS: <Locations> under "OPLX" strategies is causing the validation against the
XSD to fail, but most likely, you're aware of it.
Thanks
[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
-~----------~----~----~----~------~----~------~--~---
