FpML Issues Tracker

Summary

There is a problem today with some of the validation rules - they define a narrow context and then test constraints on elements that are out of scope for that context.

For example, take eqd-1: " Context: EquityAmericanExercise (complex type). commencementDate/adjustableDate/unadjustedDate must be equal to ../../../tradeHeader/tradeDate"

The problem with this is that tradeHeader/tradeDate is out of scope from the context of EquityAmericanExercise.

Generally seeing a path of ../../../ shows how out of scope something is.

The rule should be rewritten as: "Context: Trade (complex type). .//equityAmericanExercise/commencementDate/adjustableDate/unadjustedDate must be equal to .//tradeHeader/tradeDate"

The benefits of this are: 1. Currently the context is not really the context as the rule reaches outside of the context. 2. Accessing ancestor nodes is brittle when the schema is changed. 3. Accessing ancestor nodes is brittle when the schema is extended. For example there might be more than one ../../../tradeHeader/tradeDate in my extended schema. 4. Validation rules can be written in many ways, and given a free choice we should be adopting a method consistent with best practise, as for example defined in UML's OCL and its tools. This will help with FpML convergence and support. 5. Getting the right context makes it easier to manage revisions to the rules following schema changes.

This is just the example. There needs to be a more general rule in the Architecture for Validation. I propose the rule is:

"For the purposes of precision, extensibility, and robustness to change the structure of the Validation Rules is profiled. The rules of the profile are: 1. The context for a validation rule must always be a type. 2. The paths from the context should be node names rather than types wherever posssible. For example "equityAmericanExercise" is preferred to "element(*, EquityAmericanExercise)". 3. The context of the rule must be defined such that incorporates everything referred to in a rule. The rule must not use the ancestor or parent axis, or use them in cojunction with any other axis. For example "../../tradeHeader" is precluded.