FpML Issues Tracker

518: FpML ird – review cardinality on Stub complex type

November 7, 2007

closed

Minor

Always

Schema

Admin

mgratacos

Summary

The Stub complexType has defined as 1..* but the documentation consistently says that there can be up to two rates specified - suggest we change the cardinality to 1..2 instead.

Notes:

  • h_mcallister

    11/07/07 3:23 pm

    Agreed – one instance of Stub/floatingRate signifies the (non-interpolated) tenor applicable to the stub, two instances signify the boundary tenors for linear interpolation, more than two instances are not meaningful.

    On the subject of stubs, I suggest that we modify the content model of StubCalculationPeriodAmount to enforce the presence of at-least-one-of
    (initialStub, finalStub) – at present both are optional. This would give a
    model similar to that of eq-shared StubCalculationPeriod:













    Adopting this change is backward-compatible with all compliant (and therefore meaningful) instance docs, and renders validation rule ird-38 redundant:


    Context: StubCalculationPeriodAmount (complex type)
    Either initialStub or finalStub must be present.

  • h_mcallister

    11/07/07 3:25 pm

    Correction: the type declaration in the previous Note should read:



  • mgratacos

    11/09/07 7:40 pm

    Harry, do we need working group approval for implementing these two changes? they seem pretty straightforward to me.

  • h_mcallister

    11/12/07 4:54 pm

    Agreed, the changes are really just technical rationalisations, however I’d like to have them endorsed by the group.

  • mgratacos

    12/03/07 11:11 am

    Marc,

    Hi, we have had only favourable feedback so let’s proceed with the change – I guess we’ll be targeting the third working draft now?

    Best regards,
    Harry

  • mgratacos

    12/03/07 11:28 am

    This has been committed to the trunk and it will be published in the third working draft for version 4.4.

  • Leave an update

    You must be logged in to post an update.