529: Review element names and remove product prefixes where they are present
Modeling change recommendation: Review element names and remove product prefixes where they are present (e.g. equityEffectiveDate).
Modeling change recommendation: Review element names and remove product prefixes where they are present (e.g. equityEffectiveDate).
Modeling change recommendation: Eliminate use of substitution groups in favor of choices with a restricted list of values for underlying assets, similar to the reference obligation for CDS.
Modeling change recommendation: consolidate singlePayment and initialPayment into one type with multiple cardinality and explicit directionality. The name of this element should if possible be consistent with IRD if possible.
Modeling change recommendation to standardize payment and premium structures. For the option premiums, this will be achieved by fully implement the generic model. For other payment types, we will migrate to the content model of SimplePayment.
Modeling Task Force recommendation: Eliminate standalone adjustable[…]Date and adjusted[…]Date elements throughout the schema, and replace with the version 5 AdjustableDate types, which includes either or both.
A simple adjustment to the content model of Discounting allows business rule ird-32 to be retired – please see proposal document and modified ird schema attached.
Feedback from Harry: The explanation of how preconditions for validation rules are evaluated. The following text needs to be revised: “The Validation Preconditions only apply when specific rules reference them. The following preconditions are always to be executed relative to the root of the FpML document being validated. The context of the rule is NOT … Continued
At the moment it is just a TODO in the trunk: ISDA2002 ISDA2002Equity TODO
VersionedTradeId ought to carry an id (xsd:ID) attribute by symmetry with TradeId, enabling the versioned identifier to be referenced at the component level.
The Stub complexType has defined as 1..* but the documentation consistently says that there can be up to two rates specified – suggest we change the cardinality to 1..2 instead.