FpML-VAL Validation Rule Specifications - (HTML prototype implementation)

This email contains supporting material for Tuesday’s call. (The new specs were presented to the coordination committee today.)

---

The validation WG has adopted new validation rule specifications. Attached is a prototype HTML rendition of how rules will appear in the spec going forward.

The objective is “to improve validation rules by defining a set of principles and guidelines for writing rules and a standard format/notation for representing the rules. The motivation is to ensure the rule are precise and that the terminology used to express the rules is mutually consistent.” [Mark A.(JPM)]

Please find attached:

- ZIP – validation rule specifications proposed by JPM 5/29 and adopted by the Validation WG 6/03

- HTML ZIP – prototype implementation (of the "shared" rules) using the new presentation/specs

rules of interest:

- shared-24 uses function

- shared-25 uses condition

- shared-26-test uses multiple conditions (not a real rule)

- The new specifications required the addition of new tags in the source XML (details below)

XML coding details

Proposed additions to the XML syntax to support the new formatting of validation rules:

- <globalConditions> (formerly, <preconditions>) (used to represent “global” conditions shared across many rules. E.g., ISDA1999)

- <conditions> (new!) (used to represent conditions “local” to one rule – i.e., not shared)

- <functions> (new!) (defines a new term which has precise meaning that can be used as a clause or condition when expressing rules)

The XSL transformation used to convert the new XML syntax to HTML is backward compatible:

- Existing rules don’t have to be rewritten to produce the new HTML representation;

If none of the new tags (<function>, <condition>) are used, there’s no impact (e.g., shared-1)

Excerpt of new XML syntax to express validation rules:

</introduction>

<namespace>&fpml.namespace.uri;</namespace>

<globalConditions>

<para>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 carried through to the precondition.</para>

<condition id="ISDA3000-test">

<context datatype="yes">Trade</context>

<context datatype="yes">Contract</context>

The <el>documentation/contractualDefinitions</el> element or the <el>documentation/masterConfirmation/masterConfirmationType</el> element contains <value>ISDA3000Credit</value>.

</condition>

</globalConditions>

<functions>

<function id="same-routingId" name="same-routingId">

<description>The equivalence test is to compare the value of <el>routingId</el> and, if it exists, <el>routingId/@routingIdCodeScheme</el>.</description>

<name>routingId</name>

<type>xsd:normalizedString</type>

</parameter>

<name>routingId/@routingIdCodeScheme</name>

<type>xsd:anyURI</type>

</parameter>

</parameters>

<result>xs:boolean</result>

</function>

</functions>

<context datatype="yes">BusinessDayAdjustments</context>

<el>businessCentersReference</el> or <el>businessCenters</el> must exist if and only if …</description>

</testcases>

</rule>

…

<comment>Each routingId is unique within a set of routing Ids.</comment>

<context datatype="yes">RoutingIds</context>

<description> <el>routingId</el> must be unique and <function href=""> must evaluate to true</description>

</rule>

<comment>Each step happens on a separate date.</comment>

<condition>count(step) >= 2</condition>

<context datatype="yes">Schedule</context>

<description> <el>step/stepDate</el> must be unique.</description>

</rule>

<comment>Each step happens on a separate date.</comment>

<condition href="">

<condition>count(step) >= 2</condition>

<condition>count(step) < 10000</condition>

<context datatype="yes">Schedule</context>

<description> <el>step/stepDate</el> must be unique.</description>

</rule>

</rules>