[This message was posted by Russell Curry of Assimilate Technology, Inc. <[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/9815b3b3 - PLEASE DO NOT REPLY BY MAIL.]
> The GUI standards area is also way outside the domain of FIX. So reinventing > the wheel at FIX in general GUIs is not desired. The last thing we want is to > create some odd FIX / FIXatdl unique cascading style sheet like technology > where others have already solved those problems with good generic, cross > industry, standard solutions. Hi Rick, All: Conceptually, FIXatdl makes a lot of sense, but considering the pushback with respect to dictating the actual presentation of the algorithm parameters (in an OMS/EMS application), does it make sense to just not worry about any of it in the first place? It seems that the relationships and constraints for the different algorithm parameters are the most important aspect of FIXatdl, and if OMS/EMS developers are just going to create their own UI anyway, then the UI specifications in a FIXatdl ticket are just going to be ignored for the most part anyway... it would seem that you'd get more mileage by concentrating purely on defining the specifics of the parameters in the ticket and just ignoring the UI altogether. For instance, if a collapsible panel just becomes a "group" then we don't have to think about that collection of parameters being displayed in an e [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.
