All,
Attached is the agenda for today’s meeting.
Please also find attached the details of the issues that Lyteck
would like to discuss.
There are no minutes from the previous meeting as there was no
quorum, but a group discussion was held, details of which were forwarded by
Marc in mid-July
Regards
Pam
From: valwg@xxxxxxxx [mailto:valwg@xxxxxxxx] On
Behalf Of Lyteck Lynhiavu
Sent: 11 August 2008 17:43
To: valwg@xxxxxxxx
Subject: FpML-VAL Tomorrow's Val WG meeting
Pam,
I would like to add these points for discussion to the agenda.
1. Syntax for multiple
preconditions
a. [if firstPaymentDate and lastRegularPaymentDate both exist]
b. [if both firstPaymentDate and lastRegularPaymentDate exist]
c. [if paymentDates/firstPaymentDate exists and calculationPeriodDates/effectiveDate exists]
d. [if firstPaymentDate exists] [if lastRegularPaymentDate exists] ß preferred?
2. Terminology
a. Use of mathematical
expressions: “>=” vs. “greater than or equal to” (eqd-9,cd-37 vs.
eqd-13,cd-1b)
b. “If and only if” vs.
function iif()?
ird-1,7,
shared-1,15 http://www.fpml.org/issues/view.php?id=740
c. “If… then… else”
ird-10,11
http://www.fpml.org/issues/view.php?id=697
3. Component ordering
ln-7,8,9
http://www.fpml.org/issues/view.php?id=743
-
E.g., [n]th and [n+1]th
element
http://www.fpml.org/issues/view.php?id=766
4. Should functions be
shared across asset classes? (i.e., can we streamline definitions and maintain
reusable functions that can be reused in multiple validation rules)
-
E.g., SameCurrency in Loan, FX, CD, EQD http://www.fpml.org/issues/view.php?id=744
Thanks
for everyone’s earlier feedback. There maybe key participant apologies so I
don’t think we can through all the items but I think we should be able to find
consensus on the easier items.
Lyteck
From: valwg@xxxxxxxx [mailto:valwg@xxxxxxxx] On
Behalf Of Peter Geraghty
Sent: Friday, August 01, 2008 5:26 AM
To: valwg@xxxxxxxx
Subject: RE: FpML-VAL validation rules questions
You could require that “exists” was specified for each node in
question, so that the word “and” appeared between proper conditions e.g.,
if paymentDates/firstPaymentDate exists and calculationPeriodDates/effectiveDate exists
Alternatively, “all of” would be a more appropriate term
than “several” for cases where more than 2 nodes were involved.
Pete
From: valwg@xxxxxxxx [mailto:valwg@xxxxxxxx] On
Behalf Of mark.a.addison@xxxxxxxxxxxx
Sent: 01 August 2008 09:18
To: valwg@xxxxxxxx
Subject: RE: FpML-VAL validation rules questions
These changes
are all improving the rule in terms of making them more consistent and precise.
However, on the
point about using "both," I really do not think it adds anything and
is superfluous.
Simply listing
each node as a separate condition is sufficient and expresses that both must
exist (as Lyteck suggests.)
Consider cases
where three, four or more nodes must exist together - we surely would not write
several to express the related existence of these nodes?
Regards,
Mark.
|
"Lyteck
Lynhiavu" <LLynhiavu@xxxxxxxx>
Sent by:
valwg@xxxxxxxx
31/07/2008
21:07
|
Please respond to
valwg@xxxxxxxx
|
|
|
To
|
<valwg@xxxxxxxx>
|
|
cc
|
|
|
Subject
|
RE:
FpML-VAL validation rules questions
|
|
Thanks
Daniel and Christian for the feedback.
See
in red below (attached zip contains updated IRD rules)
From: valwg@xxxxxxxx
[mailto:valwg@xxxxxxxx] On Behalf Of Daniel.Dui@xxxxxxxxxxxxxxxxxxx
Sent: Monday, July 28, 2008 7:19 AM
To: valwg@xxxxxxxx
Subject: RE: FpML-VAL validation rules questions
Lyteck
Yes, “only” is a word to look for in rules. I
think that ird-23 and ird-24 should be reworded to use “if-and-only-if”. [Lyteck: ird-23, ird-24 changed “should only
exist if” to “exists if and only if”]
A few other points:
1.
Rule ird-9 oddly
uses “can exist”. It should probably be turned around to:
Context: InterestRateStream (complex type)
[if calculationPeriodAmount/calculation/compoundingMethod exists]
cashSettlement/cashSettlementPaymentDate
must exist
[Lyteck:
yes, it makes more sense turned around.
Note:
the original rule was “calculationPeriodAmount/calculation/compoundingMethod
can only exist if a resetDates element exists.” It looks like I made a
copy/paste error in the condition, rule should be:
Context: InterestRateStream (complex type)
[if calculationPeriodAmount/calculation/compoundingMethod exists]
resetDates
must exist
ird-9
corrected in SVN]
2.
For consistency, I’d
reword the definition of the condition “isParametric” to:
Condition: isParametric
(context: InterestRateStream) If cashflows does not exist, or cashflows/cashflowsMatchParameters contains is true.
[Lyteck:
ok – updated in SVN]
3.
I think also the
word “both” also be used in a standard way. I.e. “both X and Y…”.
I suggest rewording Rule-6 as:
ird-6 (Mandatory)
Context: InterestRateStream (complex type)
[isParametric]
[hasInitialStub] [if both paymentDates/firstPaymentDate and calculationPeriodDates/effectiveDate exist]
paymentDates/firstPaymentDate > calculationPeriodDates/effectiveDate/unadjustedDate.
[Lyteck:
Your suggestion is consistent with some rules (e.g., cd-31, cd-33, ird-36) but
inconsistent with other rules (cd-5, fx-3, fx-8, fx14). I think it makes sense
to use “both” before listing the nodes.
That
said, should we avoid “both” altogether and move toward separating sentences
using separate condition tags as it is done for ird-35 (discussed in #4 below)
and a few others (e.g., eqd-19, eqd-25)?]
4.
What happened to IRD-35?
ird-35 (Mandatory)
Context: PaymentDates (complex type)
[if firstPaymentDate exists] [if lastRegularPaymentDate exists]
firstPaymentDate < lastRegularPaymentDate.
Test cases: [Valid] [Invalid] [Invalid]
Should it not
be as follows?
ird-35 (Mandatory)
Context: PaymentDates (complex type)
[if both firstPaymentDate and lastRegularPaymentDate exist]
firstPaymentDate < lastRegularPaymentDate.
Regards
-daniel
From: valwg@xxxxxxxx
[mailto:valwg@xxxxxxxx] On Behalf Of Lyteck Lynhiavu
Sent: 25 July 2008 21:33
To: valwg@xxxxxxxx
Subject: FpML-VAL validation rules questions
We would like to add these
topics for discussion to the next agenda:
1. Terminology
a. “If and only if”
ird-1,7, shared-1,15
http://www.fpml.org/issues/view.php?id=740
o Isn’t this the same as “if” from
an implementation perspective?
o Is function iif() bringing clarity
b. “Should only exist
if” ird-23,24
o “Should” vs. “Must”
o Isn’t this the same as “if and
only if”?
c. Use of mathematical
expressions
o “>=” vs. “greater than or equal
to”
d. “If… then… else”
ird-10,11
http://www.fpml.org/issues/view.php?id=697
2. Should functions be
shared across asset classes?
-
E.g., SameCurrency, same-currency()
http://www.fpml.org/issues/view.php?id=744
3. Component ordering
ln-7,8,9
http://www.fpml.org/issues/view.php?id=743
-
E.g., [n]th and [n+1]th element
http://www.fpml.org/issues/view.php?id=766
Please find attached HTML
renditions of the validation rules* in \trunk\src\validation (4.5). Feel free
to share any thoughts through this forum before the next meeting.
Thanks, Lyteck
* FYI - Below is a summary
of the validation rules that we upgraded to conform to the new specifications.
They fall into two categories: (a) validation rules tracked as issues in Mantis
or (b) waiting to be noticed and upgraded
a. Logged as issues: The following 34 issues below
(related to the implementation of the new validation specs) have been fixed in
\trunk (FpML 4.5):
-
http://www.fpml.org/issues/view.php?id=616 cd-1
(update)
-
http://www.fpml.org/issues/view.php?id=698 eqd-3 (updated)
-
http://www.fpml.org/issues/view.php?id=672 eqd-2, eqd-4,
eqd-12, eqd-13, eqd-14 (update)
http://www.fpml.org/issues/view.php?id=672 eqd-2b, eqd-4b, eqd-12b, eqd-13b,
eqd-14b (new)
-
http://www.fpml.org/issues/view.php?id=699 eqd-6 (updated)
-
http://www.fpml.org/issues/view.php?id=700 eqd-15 (updated)
-
http://www.fpml.org/issues/view.php?id=683 eqd-19 (updated)
-
http://www.fpml.org/issues/view.php?id=684 eqd-20 (updated)
-
http://www.fpml.org/issues/view.php?id=685 eqd-23 (updated), eqd-30 (new), (pending: eqd-31, 32)
-
http://www.fpml.org/issues/view.php?id=686 eqd-25 (updated)
-
http://www.fpml.org/issues/view.php?id=701 eqd-28 (updated)
-
http://www.fpml.org/issues/view.php?id=702 eqd-29 (updated)
-
http://www.fpml.org/issues/view.php?id=759 shared-4 (updated)
-
http://www.fpml.org/issues/view.php?id=559 shared-5 (updated)
-
http://www.fpml.org/issues/view.php?id=758 shared-6 (updated)
-
http://www.fpml.org/issues/view.php?id=757 shared-7 (updated)
-
http://www.fpml.org/issues/view.php?id=756 shared-9 (updated)
-
http://www.fpml.org/issues/view.php?id=716 shared-18 (new)
-
http://www.fpml.org/issues/view.php?id=717 shared-19 (new)
-
http://www.fpml.org/issues/view.php?id=719 shared-20 (new)
-
http://www.fpml.org/issues/view.php?id=720 shared-21 (new)
-
http://www.fpml.org/issues/view.php?id=721 shared-22 (new)
-
http://www.fpml.org/issues/view.php?id=722 shared-23 (new)
-
http://www.fpml.org/issues/view.php?id=723 shared-24 (new)
-
http://www.fpml.org/issues/view.php?id=724 shared-25 (new)
-
http://www.fpml.org/issues/view.php?id=613 ird-5 (update)
-
http://www.fpml.org/issues/view.php?id=614 ird-6 (update)
-
http://www.fpml.org/issues/view.php?id=695 ird-25 (new)
-
http://www.fpml.org/issues/view.php?id=696 ird-29 (new)
-
http://www.fpml.org/issues/view.php?id=715 ird-48 (new)
-
http://www.fpml.org/issues/view.php?id=689 ird-57 (new) (reopened by Harry/ TBILL question)
-
http://www.fpml.org/issues/view.php?id=690 ird-58 (new) (reopened by Harry/ TBILL question)
-
http://www.fpml.org/issues/view.php?id=734 ln-2 (update)
-
http://www.fpml.org/issues/view.php?id=745 ln-7, ln-8, ln-9
(update)
-
http://www.fpml.org/issues/view.php?id=585 all
(precondition -> condition)
b. Not logged as issues: A second wave of changes was
applied as a result of reviewing all the other rules (not logged as issues but
requiring refactoring to conform to the new specs. The following 70 rules
contained "if" statements now refactored using local
<condition>s:
-
CD: cd-1b, cd-2, cd-5, cd-8, cd-9, cd-10, cd-12, cd-13, cd-14, cd-15,
cd-16, cd-17, cd-18, cd-25, cd-26, cd-27, cd-28, cd-29, cd-30, cd-31, cd-32,
cd-33, cd-34, cd-39, cd-41, cd-42, cd-43
-
IRD: ird-9, ird-10, ird-11, ird-35, ird-36, ird-46, ird-47
-
LOAN: ln-4, ln-5, ln-10, ln-11, ln-12, ln-14, ln-15, ln-16, ln-17, ln-18,
ln-19, ln-22, ln-24, ln-26, ln-27, ln-28, ln-30, ln-31
-
FX: fx-2, fx-3, fx-8, fx-9, fx-12, fx-13, fx-14, fx-15, fx-16, fx-20,
fx-21, fx-22, fx-26, fx-29, fx-30, fx-44, fx-45
-
REPO: repo-1
**************************************************************************************************************************
The information contained in either this email and, if applicable, the
attachment, are confidential and are intended only for the recipient. The
contents of either the email or the attachment may not be disclosed or used by
anyone other than the addressee. If you are not the intended recipient(s), any
use, disclosure, copying, or distribution is prohibited and may be unlawful. If
you have received this communication in error, please notify us by e-mail at
isda@xxxxxxxx then delete the e-mail and all attachments and any copies
thereof. This communication is part of an ISDA process and is not intended for
unauthorized use or distribution.
**************************************************************************************************************************