Re: FpML

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

Hi all

Luigi and I exchanged few ideas yesterday, which I'll try to summarize
here. I apologize in advance if my poor XML knowledge shows up :)

FpML describes a financial instrument, it is the electronic equivalent of a
term sheet.

1) We might introduce QuantLib::TermSheet classes for the financial
products we want to support. These classes (class hierarchy?) should be as
near as possible to the FpML specifications, in the limit they could be
automatically generated from the FpML Schema (xml-spy should be able to
generate C++ code from a schema definition)
2) we create a new library QuantLib-FpML which allow the parsing of a FpML
file and instantiate  QuantLib::TermSheet objects
3) gradually all QuantLib::Instrument classes will accept a TermSheet
object as constructor parameter
4) QuantLibAddin will use QuantLib-FpML to instantiate a
QuantLib::TermSheet from a FpML file and then use it to instantiate a
QuantLib::Instrument

point 2 above could be the stand-alone project QuantLib-FpML, which is
based only on the FpML specifications, mirrored with the TermSheet classes
in QuantLib.

Another different project would be how to serialize/deserialize the
QuantLibAddin objects which are not just termsheets. We will need to define
XML serialization for stochastic process, pricing engines, etc.

Does this sound reasonable?


eric ehlers wrote:
>I'm lately thinking FpML *instead of* any more general XML?

FpML should be the standard for the term sheet details. All the rest should
be our own XML specifications.

>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.
The QuantLib::TermSheet class will be extended, not the Instrument class.
The Instrument class will accept a QuantLib::TermSheet object as
constructor parameter.


>   I'm not sure we
>want the core QuantLib library to have any actual knowledge of FpML.
No, we don't

>It appears that
>many of the instruments in QuantLib are not yet represented in FpML,
I don't think so. FpML specifications are quite large and detailed, I would
be surprised if Quantlib handles a financial instrument for which there
isn't a FpML spec.


Luigi, please step in if I've misrepresented our conclusions.

ciao -- Nando