FpML Issues Tracker

(1) Isn’t there an extra negative in the suggested expression? – surely the intent of the rule, as currently expressed, is (in an informal notation):

exists(fixedRateSchedule) ne exists(resetDates),

(2) The source of the confusion lies in the refactoring of ird-1, formerly (up to 4-2 TR 2006-12-15):

‘resetDates must be present if and only if a floatingRateCalculation element is present in the calculationPeriodAmount / calculation element’

In 4-2 Recommendation the rule was re-expressed as:

‘resetDates must be present if and only if a fixedRateSchedule element is not present in the calculationPeriodAmount / calculation element’

The refactored expression was intended to subsume the extended conditions for inflation swaps (see below), and the logic was inverted in order to “future-proof” against further developments (the reasoning for the change can be found at http://www.fpml.org/_wgmail/_valwgmail/msg00081.html).

However this was a premature optimisation: not exists(fixedRateSchedule) is NOT the inverse of exists([floating|inflation]RateCalculation), and the examples were not re-validated against the new expression of the rule.

I move that the rule should be re-instated as originally conceived:

‘resetDates must be present if and only if a floatingRateCalculation or inflationRateCalculation is present in the calculationPeriodAmount / calculation element’

(3.1) valid-ird-1-01.xml is okay (conventional fixed-float swap) – maybe we should update DEM to EUR, though?

(3.2) valid-ird-1-02.xml is okay but redundant (making the swap the underlyer for a swaption doesn’t add anything to the illustrative force of the example)

(3.3) invalid-ird-1-01.xml is not invalid against the rule, which would permit floatingRateCalculation to be produced in the absence of resetDates (if the intention is that resetDates is *always* produced in the presence of floatingRateCalculation then this should have been constrained in schema).

(3.4) invalid-ird-1-02.xml makes no sense, as the use of knownAmountSchedule is inconsistent with a floating rate stream (has anyone _ever_ used knownAmountSchedule anyway?)

(3.5) invalid-ird-1-03.xml: same as for invalid-ird-1-01.xml (no difference)

(3.6) invalid-ird-1-04.xml: as for invalid-ird-1-02.xml re knownAmountSchedule, and valid-ird-1-02 re swaption underlyer

– The ird-1 rule was updated to say the following: ‘resetDates must be present if and only if a floatingRateCalculation or inflationRateCalculation is present in the calculationPeriodAmount/calculation element’.
– The change has been committed to the 4-3 branch (4.3) and trunk (4.4).

The updated rule in XQuery is:

(for $interestRateStream as element(*, InterestRateStream) in //element(*, InterestRateStream)
return )