Latest Posts

Not all validation rules apply to all views. They should be split up.

The Period Enum Term needs fuller documentation. I suggest AJ had some good description: “Term refers to time period between the effective and termination dates”. The specification of a time period Term.

The Interval definition in fpml-shared.xsd is equivalent to the built in xsd:duration. There is much better support in tools for xsd:duration than there is for Interval, which needs to be parsed back into a duration by people using the Interval. I propose replacing the use of Interval with xsd:duration. Interval is defined as: A type … Continued

This one type is a subtype of the other: https://dedicated.fpml.org/svn/fpml/trunk/src/schema/fpml-ird.xsd#StubCalculationPeriodAmount should extend https://dedicated.fpml.org/svn/fpml/trunk/src/schema/fpml-eq-shared.xsd#StubCalculationPeriod Obviously this cannot be made a subtype today, but when the MTF considers consistency of stub modelling, this should be a subtype.

In contravention of the architecture there is a floating documentation in fpml-msg.xsd. On line 447 the following appears at the schema level: Message rejected, status messages. This comment should be attached to something more specific than the schema, or should be removed.

The PositionsAsserted complex type in fpml-reconciliation.xsd has two elements with the same name: “definePosition”. This is legal XML Schema in this case because there is a choice between them. However this contravenes the FpML Architecture rules to quality a type with a unique name (name an element), see issue #603. The first “definePosition” is used … Continued

The type PaymentDetail has a choice of two elements named PaymentAmount. It would be more consistent with the Architecture (see issue #603), to have one element named paymentAmount and a Validation Rule to say you must have at least one of paymentAmount or paymentRule. Today: Payment date. A fixed payment amount. A type defining the … Continued

The element CreditCurve.currency should be renamed to CreditCurrency.obligationCurrency The problem is this contravenes the Architecture document. See issue #603. To interpret CreditCurve you need to know the sequence of the currencies because there is more than one element named currency, with different definitions.

The interepretation of the CreditCurve complex type is brittle to the element order. There are two elements inside CreditCurve that are different elements but have the same name. The name of these two elements is “currency”. Knowing which currency element is which is only possible by knowing the order of the elements. This is completely … Continued

The current text is: ISDA1992 ISDA1999Credit ISDA1999CreditSuccessorAndCreditEvents ISDA1999CreditConvertibleExchangeableAccretingObligations The text should be something like: ISDA1992 ISDA1999Credit CreditSuccessorAndCreditEvents 1999-01-01Z CreditConvertibleExchangeableAccretingObligations 1999-01-01Z