Re: Fwd: [Quantlib-dev] FpML

[Fabrice C. <fab...@gm...>]

Hello,

Allright, that's clear to me now; maybe it's one of the clearest
things in my messy brain ; )

The question is : what will be the adapted organization for
QuantLib-FpML development ?


Bonne nuit,

Fabrice

On Thu, 10 Feb 2005 21:37:57 +0000, eric ehlers <eri...@gm...> wro=
te:
> Hi Fabrice,
>=20
> On Thu, 10 Feb 2005 19:35:28 +0100, Fabrice Carrega
> <fab...@gm...> wrote:
> > Hi all,
> >
> > So I would sum up what I have understood concerning FpML / XML developm=
ent.
> >
> > - 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)
>=20
> QuantLib-FpML and QuantLibAddin are separate, and QuantLib-FpML will
> be used both by QuantLibAddin and by other QuantLib clients unrelated
> to QuantLibAddin.
>=20
> QuantLibAddin(/ObjectHandler) are just utilities peripheral to
> QuantLib which provide a high-level API that allows QuantLib to be
> accessed from spreadsheets etc.
>=20
> 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.
>=20
> QuantLibAddin would also use QuantLib-FpML as you describe above (and
> as described in more detail earlier in this thread).
>=20
> > - FpML would be translated to and from QuantLib::TermSheet
>=20
> Yes.  The purpose of QuantLib-FpML is to convert FpML >>
> QuantLib::TermSheet and vice versa.
>=20
> > - QuantLib-FpML abstract level would be implemented in ObjectHandler
>=20
> 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.
>=20
> But as mentioned above, applications which access QuantLib directly
> can use QuantLib-FpML, TermSheets etc. without reference to
> ObjectHandler/QuantLibAddin.
>=20
> > - Modifications of some QuantLib classes would be needed to implement
> > a constructor taking a TermSheet as an argument
>=20
> Yes.  Those QuantLib::Instruments which are to have an FpML
> representation will be extended to have new constructors accepting a
> TermSheet as input.
>=20
> > - There would be no direct link between FpML and QuantLib objects
>=20
> Correct.
>=20
> > - 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)
>=20
> 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.
>=20
> > Bonne soir=E9e,
> >
> > Fabrice
>=20
> Bonne soir=E9e,
>=20
> Eric
>