Re: Fwd: FpML

Posted by Ferdinando M. Ametrano-3 on
URL: http://quantlib.414.s1.nabble.com/FpML-tp10694p10702.html

Hi all

I will be declarative and redundant in the following only for the sake of
clarity, while trying to make a summary so far of the discussion. Please
feel free to disagree :) and/or blame my poor English.

>a question about data export from QuantLib objects to FpML
I don't forecast any direct connection between the QuantLib C++ library and
whatever XML layer

>which class or library would contain the method allowing one to transform a
>QuantLib object (Instrument or Termsheet) to a FpML file ?
the proposed QuantLib-FpML library should have features for bidirectional
bridging between QuantLib::TermSheet <-> FpML file

QuantLib::Instrument shouldn't be involved at all in QuantLib-FpML, because
an Instrument is a class outside the scope of the FpML specifications. A
QuantLib::Instrument accepts a QuantLib::TermSheet as constructor input
parameter and should a) copy it as internal data member b) provide a
dedicated inspector method

>    How will we write back and resubstantiate in to FpML after QuantLib
>has calculated what it needs to do?  In other words, will the parser
>be bi-directional in the event that we want to output FpML after
>calculation?
Yes, the parser should be bi-directional

>Would it be an intermediate step, creating a Termsheet from an
>Instrument (for example) and then an export method implemented within
>the Termsheet class ?
No, in order to work with FpML an user should link QuantLib-FpML. He could then
a) access a QuantLib::TermSheet inside an instance of QuantLib::Instrument
using the Instrument getTermSheet() method and serialize the TermSheet into
a FpML file
b) de-serialize a QuantLib::TermSheet from a FpML file and use it to
instantiate a QuantLib::Instrument

>So, QuantLib-FpML has not been written?
No, it hasn't. Hey David, that should be the assignment for you and your
fellows! ;-)

>I was under the impression
>that Excel and OpenOffice Spreadsheet already have a semi-stable
>QuantLibAddIn.
A semi stable QuantLibAddin not using any kind of XML.

>   How are these currently working?
as Eric wrote: "In the simplest case QuantLib is
statically linked into QuantLibAddin to create, say, a single xll
binary which is loaded into Excel.  QuantLibAddin invokes QuantLib's
native C++ interface and objects are constructed directly from native
datatypes (captured by spreadsheet formulas)."

>  Would these need
>changing once QuantLib-FpML has been sorted out?  I'm assuming, yes,
>QuantLibAddIn will need modification to output FpML.  When everything
>is working, this FpML would be parsed and finally an instrument would
>be created; calculation ouput would be returned.
once again with Eric: "The existing framework will be extended to
additionally support FpML.
So in addition to being able to construct objects from literal inputs, you
will alternatively be able to type into the spreadsheet something like

QL_OBJECT_LOAD("path/to/object_definition.xml")

[...] this uses QuantLib-FpML to construct the TermSheet object from the
file, and the TermSheet object is then passed as an input to the
constructor of the corresponding QuantLib class, which is instantiated as
an object on the spreadsheet."

>    In the process of writing up a formal proposal for the class Peter
>and I are enrolled in, we have started to understand the structure and
>history of QuantLib.
You're welcome, of course. Anyway please allow me to make clear that since
the QuantLib::Termsheet class doesn't exist yet, no direct insight can be
gained for the QuantLib-FpML project by inspecting the current QuantLib C++
library.
What we should strive for here is FpML compliance, and QuantLib will adapt
to it through the usage of the QuantLib::TermSheet class

>   One question which is not obvious to us is where
>there is a list of the QuantLibXL functions.
Eric posted a list of the functions, and said that sooner or later
QuantLibAddin will cover all those functions, superceding QuantLibXL.
Anyway as for C++ QuantLib, the existing QuantLibXL functions have no
direct relevance in the current XML thread.

>   My personal intution tells me that QuantLibXL is capable of using
>every function built in to QuantLib
No, C++ QuantLib is way larger than QuantLibXL


>   More importantly, we
>figured it is crucial to know which functions we want to implement to
>a GNUmericAddIn.  Could someone please clarify this for us?
We can export in QuantLibAddin whatever function is available in QuantLib
and we feel compelled to export (QuantLibAddin will have a Gnumeric version
along with Calc, Excel, etc.)
Anyway this discussion focus is XML.

As far as XML is concerned QuantLibAddin will have additional requirements
non covered by QuantLib-FpML. QuantLibAddin will need to
serialize/deserialize not just QuantLib::TermSheet (for which it will use
QuantLib-FpML) but also QuantLib::StochasticProcess,
QuantLib::TermStructure, etc.
A fully XML-enabled QuantLibAddin is a different project with respect to
QuantLib-FpML, and there are no formal official specifications in this case
we should adhere too. We can make up our own specs.
We could think about another library, let's call it QuantLib-XML, for the
(de)serialization of all QuantLib objects but QuantLib::TermSheet: it could
be tackled by a different team (Fabrice?), or it could be the second step
after finishing QuantLib-FpML.
QuantLibAddin would be using both QuantLib-FpML and QuantLib-XML

It goes without saying that QuantLib-FpML and QuantLib-XML might be merged
into one single library. Anyway I would prefer to start with 2 separate
projects/libraries in order to enforce a better separation of concerns.

hope it help, I look forward to your feedback

ciao -- Nando