QL FpML Object Handler Modifications

[David Brown-27]

Hello-

   After discussing with out Professor the idea of assisting with
GNUmeric implementation to QuantLibAddIn we found that our project was
not suitable.  He said that wrappers were not a good substitute for a
complete learning experience involving object oriented programming.
Therefore,  Peter and I have been working on redesigning the 'school'
project;  there seem to be too many inconsistencies that are not yet
fleshed out.

   Luigi and Eric and Walter have expounded numerous points regarding
the future structure of FpML usage and from Walter's discussions,
there appear to be some future deficienies.  (SOAP, etc.)  This email
is to stimulate a little more brainstorming, prior to finalizing out
'class project proposal'.  Here is what we have been thinking:

   Eric:  We are not clear on whether you would be implementing FpML
if we built a modified object handler subclass that encoded /
unencoded FpML (or as Luigi called it:  Serialized / Deserialized
FpML.)  We are simply asking to make sure that no one is peforming
redundant work.

   Luigi:  Could you send us some links on the current structure of
the QL_Object_Handler that woudl require modification?  Any advice is
appreciated.


   Walter:  Regarding SOAP, could you please explain the problems and
intricacies you see that we need to consider when working on this FpML
Serial./Deserial. class?



Best Wishes,
David Brown

[eric ehlers]

Hi David

Welcome back, glad to hear that your negotiations are progressing, and
looking forward to your project getting underway.

>    After discussing with out Professor the idea of assisting with
> GNUmeric implementation to QuantLibAddIn we found that our project was
> not suitable.  

I know you mentioned a Gnumeric plugin, I hadn't understood that you
were considering that for your project.

> He said that wrappers were not a good substitute for a
> complete learning experience involving object oriented programming.

I agree.  Wrapping QuantLibAddin for any specific platform is a small
technical exercise, mainly writing a Python script to autogenerate the
source for the Addin.

>    Eric:  We are not clear on whether you would be implementing FpML
> if we built a modified object handler subclass that encoded /
> unencoded FpML (or as Luigi called it:  Serialized / Deserialized
> FpML.)  We are simply asking to make sure that no one is peforming
> redundant work.

I don't think there will be a subclass of ObjectHandler, nor any
functionality in ObjectHandler for directly (De)Serializing FpML.

Irrespective of who does what, let me first reiterate my current
understanding of what needs to be done:

In QuantLib:
- implementation of TermSheet classes
- extension of Instrument classes to support new constructors
accepting TermSheet as input

In new component QuantLib-FpML:
- translation of FpML <-> TermSheet

(note that QuantLib is now FpML-enabled - independent of
ObjectHandler/QuantLibAddin)

In ObjectHandler:
- extend the abstract base class Object to include (De)Serialize
member functions (which would be pure virtual)
- extend class ObjectHandler to support (Un)Load functions (which in
turn invoke Object->(De)Serialize).

In QuantLibAddin:
- for derived Object classes - override (De)Serialize to call the code
in QuantLib-FpML appropriate for the underlying QuantLib object

Back to the question of avoiding redundant work - I definitely agree
that we need to clarify who does what - I haven't yet started to think
about what I'd do personally and it depends a lot on what you would
enjoy doing.

>    Luigi:  Could you send us some links on the current structure of
> the QL_Object_Handler that woudl require modification?  Any advice is
> appreciated.

Hopefully the comments above clarify the changes required in
ObjectHandler?  There isn't much, with the main FpML-specific
functionality implemented in QuantLib-FpML.

Hope this clarifies things.  Very much looking forward to hearing your
project proposal, please let me know what I can do to help.

Best Regards,
Eric

[Fabrice Carrega]

Hello there,


I have started reading FpML specs (which is not the best book I have
ever read, I must admit), and will need some more time to finish.

Concerning my participation, I am still interested in coding part of
the new QuantLib-FpML module, as described by Eric in his last post.

I was also thinking of contacting one of the FpML development groups
to ask them what will be the next steps in the development of this
language.


Bonne soirée,

Fabrice


On Mon, 28 Feb 2005 12:35:03 +0000, eric ehlers <[hidden email]> wrote:

> Hi David
>
> Welcome back, glad to hear that your negotiations are progressing, and
> looking forward to your project getting underway.
>
> >    After discussing with out Professor the idea of assisting with
> > GNUmeric implementation to QuantLibAddIn we found that our project was
> > not suitable.
>
> I know you mentioned a Gnumeric plugin, I hadn't understood that you
> were considering that for your project.
>
> > He said that wrappers were not a good substitute for a
> > complete learning experience involving object oriented programming.
>
> I agree.  Wrapping QuantLibAddin for any specific platform is a small
> technical exercise, mainly writing a Python script to autogenerate the
> source for the Addin.
>
> >    Eric:  We are not clear on whether you would be implementing FpML
> > if we built a modified object handler subclass that encoded /
> > unencoded FpML (or as Luigi called it:  Serialized / Deserialized
> > FpML.)  We are simply asking to make sure that no one is peforming
> > redundant work.
>
> I don't think there will be a subclass of ObjectHandler, nor any
> functionality in ObjectHandler for directly (De)Serializing FpML.
>
> Irrespective of who does what, let me first reiterate my current
> understanding of what needs to be done:
>
> In QuantLib:
> - implementation of TermSheet classes
> - extension of Instrument classes to support new constructors
> accepting TermSheet as input
>
> In new component QuantLib-FpML:
> - translation of FpML <-> TermSheet
>
> (note that QuantLib is now FpML-enabled - independent of
> ObjectHandler/QuantLibAddin)
>
> In ObjectHandler:
> - extend the abstract base class Object to include (De)Serialize
> member functions (which would be pure virtual)
> - extend class ObjectHandler to support (Un)Load functions (which in
> turn invoke Object->(De)Serialize).
>
> In QuantLibAddin:
> - for derived Object classes - override (De)Serialize to call the code
> in QuantLib-FpML appropriate for the underlying QuantLib object
>
> Back to the question of avoiding redundant work - I definitely agree
> that we need to clarify who does what - I haven't yet started to think
> about what I'd do personally and it depends a lot on what you would
> enjoy doing.
>
> >    Luigi:  Could you send us some links on the current structure of
> > the QL_Object_Handler that woudl require modification?  Any advice is
> > appreciated.
>
> Hopefully the comments above clarify the changes required in
> ObjectHandler?  There isn't much, with the main FpML-specific
> functionality implemented in QuantLib-FpML.
>
> Hope this clarifies things.  Very much looking forward to hearing your
> project proposal, please let me know what I can do to help.
>
> Best Regards,
> Eric
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
> _______________________________________________
> Quantlib-dev mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/quantlib-dev
>

[eric ehlers]

Salut Fabrice

> Concerning my participation, I am still interested in coding part of
> the new QuantLib-FpML module, as described by Eric in his last post.

Sounds good.  Once we hear back from David on his preferences maybe
there will be a clear picture of how best to divide the work.  There
is also the QuantLib-XML module to be written.

> I was also thinking of contacting one of the FpML development groups
> to ask them what will be the next steps in the development of this
> language.

Of course you're welcome to do that but is it necessary?  Earlier in
this forum it's been clarified that any instrument in QuantLib is
already represented in FpML.  Separately there are non-instrument
classes such as StochasticProcess which are not and never will be
represented in FpML, for those we write QuantLib-XML.

Bonne soirée
Eric