|
From: Keith W. <kei...@gm...> - 2007-03-13 18:58:16
|
Hmm, serialisation / data store. I think we might be talking "differently" here. Let me deal with the FPML bit first. This might be a little un-politically correct, but here goes anyway. I know a number of people who hold senior roles on the FPML committee for an assortment of different threads. It is a committee based thing that takes a little time to review stuff, agree stuff, document stuff and then publish stuff. Evidence of this is seen in the manner in which the SwapsWire people have built their own SWML and extended-FPML that deals with things that are not yet in the published FPML. There is a similar type of thing being done by the nice people at DTCC to encapsulate their electronic confirmation matching service called DerivServ. The nice people at MarkIT are also working with an extended variant of the FPML stuff. At some point this will all converge, but don't hold your breath as by the time the FPML people catch up, the others will have moved on. My suggestion had to do with the design and implementation of a data schema that would enable people who use QuantLib to store stuff in tables in a relational database. All of the holiday stuff belongs in a table. All of the day count convention could usefully be stored in a collection of tables. Having gone to the trouble of getting some market rates from somewhere, using them to calculate the zero's, strips, smiles, complicated volatility surfaces and so on for "today's" pricing, it might be nice to save "stuff" in a relational table (or several). FPML, SWML and all the other "flavours" that have to do with XML stuff, lend themselves to being mapped to a collection of relational tables in a sensible manner. There are already collections of tools that do most of that for you. There seems to be a need to apply some assistance to the choice of which-XML, and this is loosely connected to a similar decision about which-SQL. I will now take the liberty of talking to the nice people at Sybase to see just how generous they feel about professional assistance in this little venture. (No Promises, no commitments, intended as a feedback thing to test the waters) I will get back to you shortly. Regards Keith p.s. please feel free in the meantime to bombard me with questions and or flame me for not being politically correct. eric ehlers wrote: > Hi Keith, > > Many thanks for getting in touch. > > Some progress has already been made on a design for extending > QuantLibAddin to support serialization, and my first thought is > whether a common framework could serve as a basis both for > serialization (say for distributed computing) and an RDB store. > > Here are the links to the previous discussion on serialization: > > http://sourceforge.net/mailarchive/forum.php?thread_id=6507779&forum_id=4300 > > http://sourceforge.net/mailarchive/forum.php?thread_id=6539684&forum_id=4300 > > http://sourceforge.net/mailarchive/forum.php?thread_id=6540997&forum_id=4300 > > http://sourceforge.net/mailarchive/forum.php?thread_id=6543552&forum_id=4300 > > http://sourceforge.net/mailarchive/forum.php?thread_id=6700844&forum_id=4300 > > > Please also take a look at the Value Objects feature, contributed to > QuantLibAddin by Plamen Neykov. Each time a QuantLib object is > constructed in ObjectHandler, a Value Object is associated with it, > the VO comprises a snapshot of the inputs to the constructor of the QL > object, and the idea is that VOs would be used as the basis for, say, > reconstituting the same object on another machine. VOs can be > interrogated with functions ohPropertyNames() and ohPropertyValues(). > > I'd be interested to hear your reaction to these initial ideas. > > Kind Regards, > Eric > > On 3/9/07, Keith Wood <kei...@gm...> wrote: >> Greetings All, >> >> My name is Keith Wood and I currently work as the business development >> manager for a little known consulting company based in Frankfurt, >> Germany. As part of some business development work that I am currently >> doing, I find myself wanting to suggest that someone add the required >> functionality such as would allow users of QuantLib to >> Fetch/Process/Store data in a relational database. >> I envisage this as being the next step up from QuantLibAddIn where >> rather than providing the hooks to a spreadsheet, you get hooked into a >> data schema. I was thinking something along the lines of a generic >> open-source model that allowed you to "install" a bunch of tables and >> "stuff" on your favorite flavor of relational data provider. >> I find myself in the somewhat unique position of being able to call upon >> the engineering group of Sybase as resources to implement this. >> >> Is there any interest from your side in talking about this further. >> If so, who should I be talking to. >> >> Regards >> Keith Wood >> >> ------------------------------------------------------------------------- >> >> Take Surveys. Earn Cash. Influence the Future of IT >> Join SourceForge.net's Techsay panel and you'll get the chance to >> share your >> opinions on IT & business topics through brief surveys-and earn cash >> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >> >> _______________________________________________ >> QuantLib-dev mailing list >> Qua...@li... >> https://lists.sourceforge.net/lists/listinfo/quantlib-dev >> > |