FpML Issues Tracker

613: ird-5 should apply only to floating (resetting) legs

February 29, 2008

closed

Tweak

Always

Validation Rules

Admin

lyteck

Summary

Rule ird-5 when applied to valid-ird-05-01.xml makes no sense for the second swapStream ("Barclays pays the 6% fixed rate every year on a 30E/360 basis").

" ird-5 (Mandatory) Preconditions: isParametric The frequency in calculationPeriodDates/calculationPeriodFrequencymust be an integer multiple of the frequency in resetDates/resetFrequency. See also: frequency equivalence "

The problem is that resetDates is an optional element. The reset dates schedule only applies for a floating rate stream.

I suggest either we add a 'precondition' for ird-5 that the swapStream "isFloating", or add a 'precondition' that the swapStream "resets".

It seems a simpler result would be to refactor swapStream into a distinct "floatingLeg" and a "fixedLeg". Presumably that is an MTF consideration, and in the meantime I ask that the validation rule is fixed.

Notes:

  • matthew

    03/27/08 9:53 pm

    Assigning to VWG and PF-W.

  • iyermakova

    05/20/08 1:55 pm

    ValWG 2008-05-20: agreement to make the change.

  • lyteck

    07/16/08 8:13 pm

    implemented as proposed:
    – added an “isFloating” global condition to ird-5

  • matthewdr

    08/12/08 4:00 pm

    ird-5 has the guards, but as a precondition instead of as a test on the context:

    Currently:

    ird-5 (Mandatory)
    Context: InterestRateStream (complex type)
    [isParametric] [isFloating]
    The frequency in calculationPeriodDates/calculationPeriodFrequency must be an integer multiple of the frequency in resetDates/resetFrequency. See also: frequency equivalence

    Should be:
    ird-5 (Mandatory)
    Context: InterestRateStream (complex type)
    [(cashflows/cashflowsMatchParameters = true) or (cashflows not exists)] [resetDates exists ]
    The frequency in calculationPeriodDates/calculationPeriodFrequency must be an integer multiple of the frequency in resetDates/resetFrequency. See also: frequency equivalence

  • lyteck

    08/18/08 7:42 pm

    fixed as suggested by Matthew

  • matthewdr

    08/19/08 5:14 pm

    Reopening because an extra “does” was inserted in the editing:

    Currently:
    “[(cashflows/cashflowsMatchParameters = true) or (cashflows does not exists)]”

    As agreed and as per style guidelines should be:
    “[(cashflows/cashflowsMatchParameters = true) or (cashflows not exists)]”

  • lyteck

    08/19/08 6:30 pm

    I indeed inserted “does” to conform with an earlier directive from the Standards Committee (face-to-face 7/8/2008) to keep descriptions in English when possible (also see Marc’s minutes for valwg 7/15/2008 and validation rule specs)

    I find condition [x does not exist] slightly more readable than [x not exist].
    (This affects other rules)

    Please advise.

  • matthew

    08/19/08 6:56 pm

    “exists” is an XPath function in addition to being an English word. The question is do we mean it in as an English word or as an XPath function.

    We agreed at the VWG to have exists tests in the form “[xyz exists]”, which is not the agreed function style of “[exists(xyz)]”. So the VWG agreed last week to be inconsistent with itself because in simple cases it made no difference. But in this case when we add a “not” it would either be “[not(exists(xyz))]” as per the current spec, or “xyz not exists” as per current practise”. Either way [xyz does not exists]” does not make sense as English because we write “exists” rather than “exist”.

    If we follow the spec on writing rules we get “[not(exists(cashflows))]”. I would use this and change the rules on writing rules if there is diagreement.

  • lyteck

    08/19/08 7:06 pm

    corrected the typo: (does not exists) -> (does not exist)

    further feedback requested – see Matthew’s note.

  • matthew

    08/19/08 7:13 pm

    So now we have two different styles depending on whether there is a “not”:

    “[xyz exists]” – without a not
    “[xyz does not exist]” – with a not

    The first problem is having two styles is an inconsistency, and also note neither fit the VWG’s rules for writing out conditions. Using the VWG’s rules you would get:
    “[exists(xyz)]”
    “[not(exists(xyz))]”

    The second problem is that the term “exist” is not defined. We already had a protracted discussion about this in the VWG because of the previous use of “present”, “exist”, and “exists” – and we agreed to consistently use the XPath function “exists” and to use the XPath definition of “exists”. At the moment this is inconsistent with the VWG’s previous decision, and also the term “exist” is undefined – e.g. is an implied attribute that isn’t present in existence or not?

    Can’t we just stick to what the VWG agreed?

  • matthewdr

    08/26/08 1:23 pm

    Discussed at the VWG today. Agreed to implement as:

    “[exists(xyz)]”
    “[not(exists(xyz))]”

  • lyteck

    08/28/08 7:46 pm

    implemented.

  • matthewdr

    08/29/08 10:14 am

    Closed after testing.

  • Leave an update

    You must be logged in to post an update.