Re: Fwd: [Quantlib-dev] FpML

[eric e. <eri...@gm...>]

Hi Fabrice,

On Thu, 10 Feb 2005 19:35:28 +0100, Fabrice Carrega
<fab...@gm...> wrote:
> Hi all,
>=20
> So I would sum up what I have understood concerning FpML / XML developmen=
t.
>=20
> - 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)
>=20
> 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=E9e,
>=20
> Fabrice

Bonne soir=E9e,

Eric