The current schema permits but does not require the use of negative durations. The current architecture does not permit the use of negative payments/cashflows, but instead requires them to be directed. I propose the same principle be extended to durations. As an example look at the shared type Interval.
This is a proposal to express Interval more clearly and succinctly. # Current structure Today the Complex Type Interval is expressed as a sequence of periodMultiplier and period. This requires two rules: Rule 1: If the periodMultiplier is zero, then the period must have the value “D”. Rule 2: If the period has the value … Continued
The Short Form versus the Long Form of a contract should be standardized across the instrument classes. At the moment each instrument class does this differently. # EQD – has separate complex types for Short Form and Long Form. # CDS – has one type and lots of constraints (validation rules) on a ShortForm precondition … Continued
Any differences in the resulting content model should be signed off by the relevant working group
FpML-4-X has an implicit confirmation view. No operation entries should all be removed, example FpML-5-0 branch at revision 3382 file fpml-cd.xsd This element contains all the terms relevant to defining the fixed amounts/payments per the applicable ISDA definitions. FpML-4-4-4-WD-3 tag file fpml-cd.xsd This element contains all the terms relevant to defining the fixed amounts/payments per … Continued
Should use messageAddressScheme attribute as documented The data type used for identifying a message address. It includes a partyIdScheme for keeping the type backward compatible with the PartyId complex type. In the next major version, partyIdScheme attribute will be replaced by a messageAddressScheme attribute.
It is apparent across the schemas that Propert (element) names are not consistent. This is an issue to be assigned to the MTF WG. An example of this is “terminationDate”, which for CDS is named “scheduledTerminationDate”. My proposal is property (element) names be made globally consistent.
cd-33 is written partially in the form of an algorithm. It should be rewritten in the form of a rule (a constraint). The rule today is: ” Context: PeriodicPayment (complex type) cd-33 (Mandatory) If both firstPaymentDate and lastRegularPaymentDate are present, then lastRegularPaymentDate must fall precisely on a date reachable by adding an integer multiple of … Continued
cd-32 refers to elements that don’t exist at that context. Based on my experience I think the rule may be off one level on the context. The rule today: ” Context: PeriodicPayment (complex type) cd-32 (Mandatory) Preconditions: LongForm If fixedAmountCalculation exists, it must contain calculationAmount and dayCountFraction. ” IMHO what was probably meant was: ” … Continued
Validation rule cd-43 is missing test cases. The rule requires valid and invalid test cases. The rule today is: ” cd-43 (Mandatory) Preconditions: SingleName If feeLeg/initialPayment exists, then feeLeg/initialPayment/payerPartyReference/@href must be equal to generalTerms/sellerPartyReference/@href and feeLeg/initialPayment/receiverPartyReference/@href must be equal to generalTerms/buyerPartyReference/@href “