Posted by
eric ehlers on
URL: http://quantlib.414.s1.nabble.com/FpML-tp10694p10704.html
Hi Fabrice,
On Thu, 10 Feb 2005 19:35:28 +0100, Fabrice Carrega
<
[hidden email]> wrote:
> Hi all,
>
> So I would sum up what I have understood concerning FpML / XML development.
>
> - QuantLib-FpML would be a library implemented in QuantLibAddin
> permitting one to import indirectly data described in FpML in QuantLib
> (and to export a QuantLib object to FpML)
QuantLib-FpML and QuantLibAddin are separate, and QuantLib-FpML will
be used both by QuantLibAddin and by other QuantLib clients unrelated
to QuantLibAddin.
QuantLibAddin(/ObjectHandler) are just utilities peripheral to
QuantLib which provide a high-level API that allows QuantLib to be
accessed from spreadsheets etc.
Any industrial-strength app will directly use QuantLib's native C++
API, and that app can use QuantLib-FpML, TermSheets etc. without
reference to ObjectHandler/QuantLibAddin.
QuantLibAddin would also use QuantLib-FpML as you describe above (and
as described in more detail earlier in this thread).
> - FpML would be translated to and from QuantLib::TermSheet
Yes. The purpose of QuantLib-FpML is to convert FpML >>
QuantLib::TermSheet and vice versa.
> - QuantLib-FpML abstract level would be implemented in ObjectHandler
Yes, it's true that part of adapting QuantLibAddin/ObjectHandler to
support FpML will include extending ObjectHandler to provide an
abstract framework for FpML:
- The abstract base class Object would be extended to include
Serialize/Deserialize functions, which would be overridded
appropriately by the QuantLibAddin classes descended from Object
- The global ObjectHandler class may be extended to include
Load/Unload functions, which would call Object->Deserialize and
Object->Serialize.
But as mentioned above, applications which access QuantLib directly
can use QuantLib-FpML, TermSheets etc. without reference to
ObjectHandler/QuantLibAddin.
> - Modifications of some QuantLib classes would be needed to implement
> a constructor taking a TermSheet as an argument
Yes. Those QuantLib::Instruments which are to have an FpML
representation will be extended to have new constructors accepting a
TermSheet as input.
> - There would be no direct link between FpML and QuantLib objects
Correct.
> - QuantLib-XML is QuantLib-FpML evil twin for classes not described in
> the FpML standard, which development would follow the same path, BUT
> the import / export language (based on XML)
>
> a) needs to be chosen (if existing)
> b) or needs to be created (if not)
I'd say that QuantLib classes which need to be (de)serialized, but
which are outside the scope of FpML, will be (de)serialized to/from
XML, using a format defined by us - this is the purpose of the
QuantLib-XML module Nando mentioned.
> Bonne soirée,
>
> Fabrice
Bonne soirée,
Eric