FpML Issues Tracker
closed
Major
N/A
Validation Rules
danieldui
danieldui
Summary
The IRD rules define two conditions: isFloating and hasInitialStub, but they are not used in the rules themselves.
I am looking at FpML 4.6.4 LCWD-1.
For example, I suggest to change rule ird-59 from:
XPath Description: Context: InterestRateStream (complex type) [exists(resetDates)] id(resetDates/calculationPeriodDatesReference/@href) is calculationPeriodDates
to:
XPath Description: Context: InterestRateStream (complex type) [isFloating] id(resetDates/calculationPeriodDatesReference/@href) is calculationPeriodDates
All rules should be looked at to see if similar changes are necessary.
Notes:
h_mcallister
07/30/09 3:42 pm
I disagree.
The condition “isFloating” is defined as:
(context: InterestRateStream) resetDates exists
– so is equivalent to the expression ‘exists(resetDates)’.
However I don’t see a reason to use the derived condition in place of the equivalent direct expression – the effect is obfuscatory.
If we can’t find a use for the ‘isFloating’ condition, it should be retired.
– BTW, I note that the definition of ‘hasInitialStub’ is still incorrect. The condition should be defined as: ‘exists(calculationPeriodDates/firstRegularPeriodStartDate)’, *not* ‘exists(paymentDates/firstPaymentDate)’
danieldui
08/05/09 10:25 am
I don’t have a strong opinion. I think that if isFloating is defined, it should be used, otherwise it should be removed.
I think that using “isFloating” makes clearer that the constraint applies to a floating leg. Checking that resetDates is pupulated just happens to be an easy way to identify a floating leg.
mgratacos
08/11/09 1:41 pm
Val WG decision:
– Use isFloating in ird-59
– Check through the rules whether isFloating can be applied.
– Remove the ‘hasInitialStub’ condition since it is not being used.
– Check through the rules whether a corrected ‘hasInitialStub’ condition could be used.
mgratacos
09/02/10 5:45 pm
I maintain my objection to implementing rule ird-59 in terms of the isFloating function. The rule is directly concerned with the content of resetDates, not whether the leg is Floating (albeit a floating leg must contain resetDates) – the use of the function as a proxy for the existence of resetDates is obfuscatory.
As an aside, the existence of the rule suggests that the element ResetDates/calculationPeriodDatesReference is redundant. The rule seeks to enforce the condition that resetDates/calculationPeriodDatesReference always points to the calcuationPeriodDates component of the common ancestor InterestRateStream – but this being the case, it becomes a matter of convention, the use of the element is stereotyped and adds no expressive value to the message.
If we agree that the ird-59 is correct, then the corollary is that ResetDates/calculationPeriodDatesReference should be removed altogether in the FpML 5-x series.
Best regards,
Harry
danieldui
09/21/10 12:01 pm
OK, reconsidering this issue. I think I finally see Harry’s point and I think that he’s correct. The rule is about reset dates not about floating legs. Using isFloating is therefore confusing.
I also like the possibility of removing the rule altogether, if calculationPeriodDatesReference is really redundant. We need to check what the architecture docs say about usage of date references and discuss at the next meeting.
lyteck
06/21/11 7:51 pm
deleted isFloating and hasInitialStub global conditions from IRD rules (rules-english-ird.xml) as per valwg 6/21/2011.
danieldui
07/05/11 1:29 pm
All done.
Updated 4.x and 5.x branch.