|
From: eric e. <eri...@gm...> - 2005-02-09 16:41:21
|
Hi David [cc to quantlib-dev] On Wed, 9 Feb 2005 10:34:06 -0500, David Brown <doc...@gm...> wrote: > Eric- > > Everything here sounds great. My questions regard the relative > scopes of our programming intent. Please assist me if my questions > are, unbeknownst to me, very naive in nature. In any event, we all > agree that it would be good to: > > 1) Develop QuantLibAddIn to handle multiple applications: Excel, > OpenOffice, GnomeOffice, StatPro, Matlab, Maple, etc. Yes. The existing QuantLibAddin prototype already supports Excel and OpenOffice Calc, but the idea is to support any platform for which there is demand. > 2) Develop QuantLibAddIn to handle XML (and FpML). Yes. I'm lately thinking FpML *instead of* any more general XML? The main change would be to the QuantLibAddin classes descended from Object to wrap QuantLib classes (the source files in QuantLibAddin\qla\objects) - these classes would be extended to support Serialize/Deserialize. In addition the ObjectHandler would be extended to support Load/Unload functions which could be called from spreadsheets or other QuantLibAddin clients. > 3) Develop QuantLib to handle XML (and FpML). > 2 and 3 will require redesiging parts of QuantLib to > a) handle XML type conventions > OR > b) redesign the structure of QuantLib objects to be XML > compliant and possibly over-featured versions of XML > objects (FpML) I was assuming b) - where an FpML instrument definition calls for an attribute which is lacking from the corresponding QuantLib class, the QuantLib class is extended to support that attribute. I'm not sure we want the core QuantLib library to have any actual knowledge of FpML. Luigi and Nando are the people to comment on proposed enhancements to QuantLib. > 4) Possibly consider becoming involved in FpML architect'ing, in > order to assist in the future implementation of new XML/FpML features > that are already in QuantLib. That hadn't occurred to me but it's a great idea. It appears that many of the instruments in QuantLib are not yet represented in FpML, so we need to cater for that somehow - wait until FpML catches up, or make the appropriate extensions to FpML and try to get them included in the standard? > This all becomes confusing when we consider where to add XML > functionality. It seems that the logical way to do this would be to > add the functionals as in #3, straight to the core program or API. I > may not fully understand how QuantLibAddIn communicates with QuantLib, > but it seems that it would be easy and natural for QuantLibAddIn to > pass questions or queries to QuantLib sitting as a dll/vbx/ocx etc or > sitting somewhere on a server, depending on the configuration. My assumption so far is that the framework for FpML support appears in ObjectHandler, with each QuantLibAddin Object-derived class implementing the details appropriate for the corresponding QuantLib class. But this is very much open to discussion. > Best Wishes, > David Brown David, many thanks for getting in touch, looking forward to getting this moving. Best Regards, Eric |