> 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
>