FpML

[David Brown-27]

Hello Everyone!

   My name is David Brown.  I am a graduate student in the United
States taking an Object-Oriented Software Engineering course.  While
browsing through the QuantLib Project's website, I saw that various
things still need work to enhance the power of QuantLib.
   As part of the class that I am taking, we are supposed to find
'customers' to design a project.  After the project is 'planned', it
will be bid upon by our fellow classmates.  At this point the project
will be coded and designed by a total of four or five graduate student
computer scientists.
   My reason for posting this to everyone is that I have a long-term
interest in becoming involved in Financial Software Programming.
Therefore, it was logical for me to try and help a project like
QuantLib.
   I do not know the status of large portions of the project.  The
archive filled in my knowledge about a few things, but there are still
many things I do not have the slightest idea about.  It would be very
nice if someone on this list group could take myself and my fellow
classmates on as 'service providers'.
   Clearly, I am not selling anything here.  If someone wanted to be
our 'customers', they would simply have to assist us as our mentor.
We would develop whatever snippets of QuantLib that are feasible in
approximately 12 man-month hours.  (I do not believe in the myth of
the man-month nor the antiquated Waterfall development method, but my
professor wants us to stick to it.)


In any event, thank you for all of your help and time!

David Brown
[hidden email]


p.s.
I have a natural attraction towards FpML / XML interfacing with QuantLib.

[Fabrice Carrega]

Hello,

I am a French student interested in QuantLib development. I have just
finished my Master program and will take a training course, starting
next week, about risk management. I have contacted Ferdinando & Luigi
in late december, who told me they needed people for FpML development
for the QuantLib Addin.

I had no time in january to work on this task but I wanted to do start
this week and continue during my internship.

Maybe we could work together on this project.

Best regards,

Fabrice Carrega

On Mon, 7 Feb 2005 00:53:15 -0500, David Brown <[hidden email]> wrote:

> Hello Everyone!
>
>    My name is David Brown.  I am a graduate student in the United
> States taking an Object-Oriented Software Engineering course.  While
> browsing through the QuantLib Project's website, I saw that various
> things still need work to enhance the power of QuantLib.
>    As part of the class that I am taking, we are supposed to find
> 'customers' to design a project.  After the project is 'planned', it
> will be bid upon by our fellow classmates.  At this point the project
> will be coded and designed by a total of four or five graduate student
> computer scientists.
>    My reason for posting this to everyone is that I have a long-term
> interest in becoming involved in Financial Software Programming.
> Therefore, it was logical for me to try and help a project like
> QuantLib.
>    I do not know the status of large portions of the project.  The
> archive filled in my knowledge about a few things, but there are still
> many things I do not have the slightest idea about.  It would be very
> nice if someone on this list group could take myself and my fellow
> classmates on as 'service providers'.
>    Clearly, I am not selling anything here.  If someone wanted to be
> our 'customers', they would simply have to assist us as our mentor.
> We would develop whatever snippets of QuantLib that are feasible in
> approximately 12 man-month hours.  (I do not believe in the myth of
> the man-month nor the antiquated Waterfall development method, but my
> professor wants us to stick to it.)
>
> In any event, thank you for all of your help and time!
>
> David Brown
> [hidden email]
>
> p.s.
> I have a natural attraction towards FpML / XML interfacing with QuantLib.
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Quantlib-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[eric ehlers]

Hi David

Many thanks for your message.  There is a requirement to XML-enable
the QuantLibAddin component that I'm working on - so perhaps you and
your fellow service providers would consider taking on QuantLibAddin
as your client?  (I don't believe in the myth of the man-month either
by the way :) ).

QuantLibAddin is a high level API for QuantLib, allowing QuantLib to
be loaded into end-user tools such as spreadsheets.  QuantLibAddin
depends on a separate ObjectHandler component for maintaining a
repository of objects (representing QuantLib classes).

Below are links to the design documents for QuantLibAddin and ObjectHandler:
http://www.quantlib.org/quep/quep011.html
http://www.quantlib.org/quep/quep012.html

The notes at the end of QuEP11 give a brief summary of the XML
requirement.  (I talk about XML but FpML might be more appropriate).

Maybe you could look that over and get back to me (here via
quantlib-dev) if it sounds interesting.  The first release of
QuantLibAddin is a couple of weeks away but the latest CVS snapshot is
working and you might want to download that to see QuantLibAddin in
action in Excel.

QuantLibAddin is just a small addon to the core QuantLib library where
all the analytics are implemented.  If you prefer instead to work
directly on QuantLib, Luigi and Nando could give you better direction
there.

Regards
Eric

[eric ehlers]

Hi Fabrice

Many thanks for your message.  You've seen my response to David,
perhaps you could look through that and see if any of it interests
you?  As to whether you and David collaborate, I'll leave that to the
two of you, but there's plenty of work to do on QuantLibAddin -
XML-related and otherwise - so if any of the outstanding tasks looks
interesting please just email quantlib-dev to get the ball rolling.

Regards
Eric

[Fabrice Carrega]

Hello,

Well, I think we first should concentrate our efforts on FpML
integration in ObjectHandler / QuantLibAddin, and particularly FpML
Serialization / Deserialization.

FpML Architecture 2.0 specs & FpML 4.0 recommandations can be found at
www.fpml.org.

There are some examples using different XSD files aivailable for
download. I will study a bit theses docs during the next days.

I have created a mailing list for QL-FpML developement, but we could
maybe only use the QuantLib-Dev mailing list.

To finish, just a question for my personal curiosity, is there any
project of a web service interface for QuantLib ?

Regards

Fabrice

[eric ehlers]

> Well, I think we first should concentrate our efforts on FpML
> integration in ObjectHandler / QuantLibAddin, and particularly FpML
> Serialization / Deserialization.

Sounds good.  I'm no FpML expert but I think the main questions are -
- does QuantLib support FpML?  There may be cases where QuantLib
classes lack the attributes that FpML expects, in which case we could
make an argument for extending QuantLib.
- does FpML support QuantLib?  It looks like there are products in
QuantLib which don't yet have an FpML representation.

> There are some examples using different XSD files aivailable for
> download. I will study a bit theses docs during the next days.

Great.  I think the subsequent steps would be for us to agree here the
general scope of your contribution, and for you to follow up with a
design document describing your proposal.

> I have created a mailing list for QL-FpML developement, but we could
> maybe only use the QuantLib-Dev mailing list.

I personally prefer the latter.

> To finish, just a question for my personal curiosity, is there any
> project of a web service interface for QuantLib ?

I don't think so.  There are a several examples of web-based pricers
powered by QuantLib - some linked to from the main QuantLib website,
others independent.  It would be great to see a full-fledged web
service, for example a server accepting requests from spreadsheets or
other clients, we could talk about that longer term.

Regards
Eric

[eric ehlers]

Hi David

[cc to quantlib-dev]

On Wed, 9 Feb 2005 10:34:06 -0500, David Brown <[hidden email]> wrote:
> Eric-
>
>    Everything here sounds great.  My questions regard the relative
> scopes of our programming intent.  Please assist me if my questions
> are, unbeknownst to me, very naive in nature.  In any event, we all
> agree that it would be good to:
>
> 1)  Develop QuantLibAddIn to handle multiple applications:  Excel,
> OpenOffice, GnomeOffice, StatPro, Matlab, Maple, etc.

Yes.  The existing QuantLibAddin prototype already supports Excel and
OpenOffice Calc, but the idea is to support any platform for which
there is demand.

> 2)  Develop QuantLibAddIn to handle XML (and FpML).

Yes.  I'm lately thinking FpML *instead of* any more general XML?  The
main change would be to the QuantLibAddin classes descended from
Object to wrap QuantLib classes (the source files in
QuantLibAddin\qla\objects) - these classes would be extended to
support Serialize/Deserialize.  In addition the ObjectHandler would be
extended to support Load/Unload functions which could be called from
spreadsheets or other QuantLibAddin clients.

> 3)  Develop QuantLib to handle XML (and FpML).
>               2 and 3 will require redesiging parts of QuantLib to
>                  a)  handle XML type conventions
>                                OR
>                  b)  redesign the structure of QuantLib objects to be XML
>                        compliant and possibly over-featured versions of XML
>                        objects  (FpML)

I was assuming b) - 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.  I'm not sure we
want the core QuantLib library to have any actual knowledge of FpML.
Luigi and Nando are the people to comment on proposed enhancements to
QuantLib.

> 4)  Possibly consider becoming involved in FpML architect'ing, in
> order to assist in the future implementation of new XML/FpML features
> that are already in QuantLib.

That hadn't occurred to me but it's a great idea.  It appears that
many of the instruments in QuantLib are not yet represented in FpML,
so we need to cater for that somehow - wait until FpML catches up, or
make the appropriate extensions to FpML and try to get them included
in the standard?

>   This all becomes confusing when we consider where to add XML
> functionality.  It seems that the logical way to do this would be to
> add the functionals as in #3, straight to the core program or API.  I
> may not fully understand how QuantLibAddIn communicates with QuantLib,
> but it seems that it would be easy and natural for QuantLibAddIn to
> pass questions or queries to QuantLib sitting as a dll/vbx/ocx etc or
> sitting somewhere on a server, depending on the configuration.

My assumption so far is that the framework for FpML support appears in
ObjectHandler, with each QuantLibAddin Object-derived class
implementing the details appropriate for the corresponding QuantLib
class.  But this is very much open to discussion.

> Best Wishes,
> David Brown

David, many thanks for getting in touch, looking forward to getting this moving.

Best Regards,
Eric

[Fabrice Carrega]

Well, I think we do not have the choice.

First we must implement FpML within QL as far as possible, as there
are existing and compatible definitions of the same classes in QL &
FpML, this would imply maybe, as said, QL expansions.

Then, we would have no other choice than following FpML future growth
and make the FpML module available in QL as close as possible from
FpML new specs.


Regards,

Fabrice

> Sounds good.  I'm no FpML expert but I think the main questions are -
> - does QuantLib support FpML?  There may be cases where QuantLib
> classes lack the attributes that FpML expects, in which case we could
> make an argument for extending QuantLib.
> - does FpML support QuantLib?  It looks like there are products in
> QuantLib which don't yet have an FpML representation.

[Ferdinando M. Ametrano-3]

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

[Fabrice Carrega]

Ooops, I didn't sent the message to the QuantLib-dev list

Hello,

Just a question about data export from QuantLib objects to FpML, which
class or library would contain the method allowing one to transform a
QuantLib object (Instrument or Termsheet) to a FpML file ?

Would it be an intermediate step, creating a Termsheet from an
Instrument (for example) and then an export method implemented within
the Termsheet class ?

Regards,

Fabrice

[David Brown-27]

Hi Everyone-   Just wanted to respond to Nando's fantastic points he
wrote earlier:

>>2) we create a new library QuantLib-FpML which allow the parsing of a FpML
file and instantiate  QuantLib::TermSheet objects

   How will we write back and resubstantiate in to FpML after QuantLib
has calculated what it needs to do?  In other words, will the parser
be bi-directional in the event that we want to output FpML after
calculation?

>>4) QuantLibAddin will use QuantLib-FpML to instantiate a
QuantLib::TermSheet from a FpML file and then use it to instantiate a
QuantLib::Instrument

So, QuantLib-FpML has not been written?  I was under the impression
that Excel and OpenOffice Spreadsheet already have a semi-stable
QuantLibAddIn.  How are these currently working?  Would these need
changing once QuantLib-FpML has been sorted out?  I'm assuming, yes,
QuantLibAddIn will need modification to output FpML.  When everything
is working, this FpML would be parsed and finally an instrument would
be created; calculation ouput would be returned.




Peace,
DB

[eric ehlers]

Hi David

>> 4) QuantLibAddin will use QuantLib-FpML to instantiate a
>> QuantLib::TermSheet from a FpML file and then use it to instantiate a
>> QuantLib::Instrument

> So, QuantLib-FpML has not been written?  

Correct.

> I was under the impression
> that Excel and OpenOffice Spreadsheet already have a semi-stable
> QuantLibAddIn.  How are these currently working?  
> Would these need
> changing once QuantLib-FpML has been sorted out?  I'm assuming, yes,
> QuantLibAddIn will need modification to output FpML.  When everything
> is working, this FpML would be parsed and finally an instrument would
> be created; calculation ouput would be returned.

You seem to be thinking in terms of QuantLibAddin and QuantLib
exclusively speaking FpML to each other in some kind of client-server
or peer-to-peer relationship.  In the simplest case QuantLib is
statically linked into QuantLibAddin to create, say, a single xll
binary which is loaded into Excel.  QuantLibAddin invokes QuantLib's
native C++ interface and objects are constructed directly from native
datatypes (captured by spreadsheet formulas).

The existing framework will be extended to additionally support FpML.
So in addition to being able to construct objects from literal inputs,
you will alternatively be able to type into the spreadsheet something
like

QL_OBJECT_LOAD("path/to/object_definition.xml")

As Nando says this uses QuantLib-FpML to construct the TermSheet
object from the file, and the TermSheet object is then passed as an
input to the constructor of the corresponding QuantLib class, which is
instantiated as an object on the spreadsheet.

> Peace,
> DB

Harmony,
Eric

[Ferdinando M. Ametrano-3]

Hi all

I will be declarative and redundant in the following only for the sake of
clarity, while trying to make a summary so far of the discussion. Please
feel free to disagree :) and/or blame my poor English.

>a question about data export from QuantLib objects to FpML
I don't forecast any direct connection between the QuantLib C++ library and
whatever XML layer

>which class or library would contain the method allowing one to transform a
>QuantLib object (Instrument or Termsheet) to a FpML file ?
the proposed QuantLib-FpML library should have features for bidirectional
bridging between QuantLib::TermSheet <-> FpML file

QuantLib::Instrument shouldn't be involved at all in QuantLib-FpML, because
an Instrument is a class outside the scope of the FpML specifications. A
QuantLib::Instrument accepts a QuantLib::TermSheet as constructor input
parameter and should a) copy it as internal data member b) provide a
dedicated inspector method

>    How will we write back and resubstantiate in to FpML after QuantLib
>has calculated what it needs to do?  In other words, will the parser
>be bi-directional in the event that we want to output FpML after
>calculation?
Yes, the parser should be bi-directional

>Would it be an intermediate step, creating a Termsheet from an
>Instrument (for example) and then an export method implemented within
>the Termsheet class ?
No, in order to work with FpML an user should link QuantLib-FpML. He could then
a) access a QuantLib::TermSheet inside an instance of QuantLib::Instrument
using the Instrument getTermSheet() method and serialize the TermSheet into
a FpML file
b) de-serialize a QuantLib::TermSheet from a FpML file and use it to
instantiate a QuantLib::Instrument

>So, QuantLib-FpML has not been written?
No, it hasn't. Hey David, that should be the assignment for you and your
fellows! ;-)

>I was under the impression
>that Excel and OpenOffice Spreadsheet already have a semi-stable
>QuantLibAddIn.
A semi stable QuantLibAddin not using any kind of XML.

>   How are these currently working?
as Eric wrote: "In the simplest case QuantLib is
statically linked into QuantLibAddin to create, say, a single xll
binary which is loaded into Excel.  QuantLibAddin invokes QuantLib's
native C++ interface and objects are constructed directly from native
datatypes (captured by spreadsheet formulas)."

>  Would these need
>changing once QuantLib-FpML has been sorted out?  I'm assuming, yes,
>QuantLibAddIn will need modification to output FpML.  When everything
>is working, this FpML would be parsed and finally an instrument would
>be created; calculation ouput would be returned.
once again with Eric: "The existing framework will be extended to
additionally support FpML.
So in addition to being able to construct objects from literal inputs, you
will alternatively be able to type into the spreadsheet something like

QL_OBJECT_LOAD("path/to/object_definition.xml")

[...] this uses QuantLib-FpML to construct the TermSheet object from the
file, and the TermSheet object is then passed as an input to the
constructor of the corresponding QuantLib class, which is instantiated as
an object on the spreadsheet."

>    In the process of writing up a formal proposal for the class Peter
>and I are enrolled in, we have started to understand the structure and
>history of QuantLib.
You're welcome, of course. Anyway please allow me to make clear that since
the QuantLib::Termsheet class doesn't exist yet, no direct insight can be
gained for the QuantLib-FpML project by inspecting the current QuantLib C++
library.
What we should strive for here is FpML compliance, and QuantLib will adapt
to it through the usage of the QuantLib::TermSheet class

>   One question which is not obvious to us is where
>there is a list of the QuantLibXL functions.
Eric posted a list of the functions, and said that sooner or later
QuantLibAddin will cover all those functions, superceding QuantLibXL.
Anyway as for C++ QuantLib, the existing QuantLibXL functions have no
direct relevance in the current XML thread.

>   My personal intution tells me that QuantLibXL is capable of using
>every function built in to QuantLib
No, C++ QuantLib is way larger than QuantLibXL


>   More importantly, we
>figured it is crucial to know which functions we want to implement to
>a GNUmericAddIn.  Could someone please clarify this for us?
We can export in QuantLibAddin whatever function is available in QuantLib
and we feel compelled to export (QuantLibAddin will have a Gnumeric version
along with Calc, Excel, etc.)
Anyway this discussion focus is XML.

As far as XML is concerned QuantLibAddin will have additional requirements
non covered by QuantLib-FpML. QuantLibAddin will need to
serialize/deserialize not just QuantLib::TermSheet (for which it will use
QuantLib-FpML) but also QuantLib::StochasticProcess,
QuantLib::TermStructure, etc.
A fully XML-enabled QuantLibAddin is a different project with respect to
QuantLib-FpML, and there are no formal official specifications in this case
we should adhere too. We can make up our own specs.
We could think about another library, let's call it QuantLib-XML, for the
(de)serialization of all QuantLib objects but QuantLib::TermSheet: it could
be tackled by a different team (Fabrice?), or it could be the second step
after finishing QuantLib-FpML.
QuantLibAddin would be using both QuantLib-FpML and QuantLib-XML

It goes without saying that QuantLib-FpML and QuantLib-XML might be merged
into one single library. Anyway I would prefer to start with 2 separate
projects/libraries in order to enforce a better separation of concerns.

hope it help, I look forward to your feedback

ciao -- Nando

[Fabrice Carrega]

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)

- FpML would be translated to and from QuantLib::TermSheet

- QuantLib-FpML abstract level would be implemented in ObjectHandler

- Modifications of some QuantLib classes would be needed to implement
a constructor taking a TermSheet as an argument

- There would be no direct link between FpML and QuantLib objects

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

Any mistake ?

Bonne soirée,

Fabrice

[eric ehlers]

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

[Fabrice Carrega]

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 <[hidden email]> wrote:

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

[Luigi Ballabio]

Hello,

On 02/10/05 23:24:07, Fabrice Carrega wrote:
>
> The question is : what will be the adapted organization for
> QuantLib-FpML development ?

To begin with, we can create an empty QuantLib-FpML module on the CVS  
server to which you and David will be given write access (we'll need your  
Sourceforge user names for this.) This way you'll have a common repository  
for working on the project, and interested parties will be able to look at  
your latest and greatest.

Also, you might want to choose one or two simple instruments to tackle as  
test cases (European stock option? Zero-coupon bond?) This way I can go  
ahead and start implementing their term-sheet thing in the library while  
you set up the project.

As for organizing the development proper: we'll be there for answering any  
questions and to help out when possible, but you and David are in charge---
it's up to you to choose what suits you best...

Later,
        Luigi


----------------------------------------

Things should be made as simple as possible, but no simpler.
-- Albert Einstein

[Fabrice Carrega]

Bonjour,

My sourceforge account is fcarrega.

Here is a proposal :

Concerning development, I will take firstly a little time to read some
litterature about FpML  and draw a first UML model.

If you approve it, then I'll start coding.


Bonne journée,

Fabrice