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

This email contains updated material for next call. (includes refinements Mark and I added to functions to support XPath tests and cardinality of parameters – see function same-currency in generated HTML as an example)

---

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>

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

<description>The equivalence test is to compare currencies are the same. (Note: This is a test implementation of the "same-currency" condition used in other validation rule pages, not used in any shared rules on this page.)</description>

<name>money</name>

<type>fpml:Money</type>

</parameter>

</parameters>

<result>xs:boolean</result>

<test>All (<el>money/currency</el> and <el>money/currency/@currencyScheme</el>) must be the same</test>

</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>