FpML Issues Tracker
closed
Minor
Always
Validation Rules
MarkAddison
None
Summary
Rule ird-7: " Preconditions: isParametric calculationPeriodAmount/calculation/compoundingMethod exists if and only if the frequencies in paymentDates/paymentFrequency and calculationPeriodDates/calculationPeriodFrequency are different. See also: frequency equivalence. "
There could be two possible interpretations:
if frequencies in paymentDates/paymentFrequency and calculationPeriodDates/calculationPeriodFrequency are different, then calculationPeriodAmount/calculation/compoundingMethod MUST be present
OR
if frequencies in paymentDates/paymentFrequency and calculationPeriodDates/calculationPeriodFrequency are different, then calculationPeriodAmount/calculation/compoundingMethod COULD be present
Notes:
h_mcallister
06/02/08 12:16 pm
This ambiguity has always been present. The schema annotation for the element (unchanged since FpML 3-0) states:
“If more that [sic] one calculation period contributes to a single payment amount this element specifies whether compounding is applicable, and if so, what compounding method is to be used. This element must only be included when more that [sic] one calculation period contributes to a single payment amount.”
This has the force of the second interpretation i.e. compoundingMethod _could_ be present, but is not mandated.
As of FpML 4-0, the element content is controlled by CompoundingMethodEnum = {Flat, Straight, None}.
Then in the case where more than one calculation period contributes to a single payment, but no compounding is applied, the implementor is faced with a choice of representations i.e. compoundingMethod present with value = ‘None’ _or_ compoundingMethod absent.
The availability of the enum value ‘None’ suggests that we expect the element to be produced (otherwise why bother with this value), and I suspect that this was the original intention, only the schema annotation & the validation rule were drafted a little too loosely.
I think we would agree that the explicit represenation is preferrable – the question is whether we want to invalidate documents in which compounding method _could_ be present, but is not produced.
Lastly, we have been here before, see: http://fpml.com/_wgmail/_valwgmail/msg00131.html
andrew
06/05/08 12:21 pm
I disagree that there is any lack of preciseness here. The problem is that statements including ‘if and only if’ are awkward to interpret in English.
The text for this rule was derived from the first order predicate calculus expressions used in the CLiX implementation of the rule which resembles this:
iff (exists compondingMethod, frequencies are different)
[ iff (P,Q) is equivalent to C or Java’s ‘P == Q’ ]
The statement will be true when:
1. compoundingMethod does exist and the frequencies are different, or
2. compoundingMethod does not exist and the frequencies are the same.
The first version of your suggested replacement text handles the first case, but neither of your suggestions handle the second. The original text handles both when read correctly.
h_mcallister
06/05/08 12:34 pm
I agree with Andrew’s reading of the rule.
Then the presence of compoundingMethod is mandated when the frequencies differ, and prohibited when they are the same.
We should strengthen the language of the schema annotation to re-inforce the point.
matthewdr
12/15/08 11:08 am
The current definition is:
”
iff(exists(calculationPeriodAmount/calculation/compoundingMethod), different-frequencies((paymentDates/paymentFrequency, calculationPeriodDates/calculationPeriodFrequency)))
”
Based on Harry’s feedback this should be changed to:
”
exists(calculationPeriodAmount/calculation/compoundingMethod) eq different-frequencies((paymentDates/paymentFrequency, calculationPeriodDates/calculationPeriodFrequency))
”
The English Description in the notes above from Harry and Andrew is better than the current one in the rule. Whether the current one is “awkward” or “imprecise” doesn’t matter if we can agree the proposed replacement is better:
”
The existence of compoundingMethod is required when the frequencies differ, and prohibited when they are the same.
”
matthewdr
12/16/08 2:20 pm
Agreed at VWG today to implement as proposed.
lyteck
12/16/08 8:02 pm
implemented as agreed.
”
ird-7 (Mandatory)
Context: InterestRateStream (complex type)
English Description:
The existence of compoundingMethod is required when the frequencies differ, and prohibited when they are the same.
Formal Description:
exists(calculationPeriodAmount/calculation/compoundingMethod) eq different-frequencies((paymentDates/paymentFrequency, calculationPeriodDates/calculationPeriodFrequency))
”