FpML Issues Tracker
The Credit Derivatives "Conditions" are derived values added to new Nodes (elements and attributes) defined by the condition.
For example: " Condition: ISDA1999Credit (context: Trade) (context: Contract) At least one of documentation/contractualDefinition element and documentation/masterConfirmation/masterConfirmationType element exists and contains the string "ISDA1999Credit".
Formal description: some $document in (//element(*, Trade) | //element(*, Contract))/documentation/(contractualDefinitions | masterConfirmation/masterConfirmationType) satisfies contains($document, "ISDA1999Credit") "
This defines a new Node named "ISDA1999Credit" on every Trade and Contract type. It provides a derivation rule, which is included in the description.
We added a lot of clarity by adding the contexts to these definitions. Making this change was a very good thing.
There is a problem with the first two sentences: "The Validation Conditions only apply when specific rules reference them. The following conditions are always to be executed relative to the root of the FpML document being validated."
#1 The first issue is the second sentence contradicts the Context given in the definition of the Condition. I suggest it be corrected or struck out.
#2 The second issue is the first sentence is a nonsense as it seems to be trying to control the application of rules. When we validate with the validation rules, all the rules apply each time. It is the contexts which determine which rules 'fire', nothing else. I suggest this is struck out.
#3 The third issue is how do we refer to these conditions in the rules referencing them? So far we have used $ISDA1999Credit to refer to the first condition, as if it was an XPath variable. The problem with this approach is that it only works if each condition appears once. As each condition appears once per Context, and the context appears many times then we need a way to distinguish between all the different $ISDA1999Credit. I suggest that for each Conditions context we define a name, a datatype and treat it as a derived element or attribute on the context. That way when I have a Valuation with hundreds of trades the rules still work. At the moment the rules break when there is more than one trade in a message.
" Name: isda1999Credit Node: element
English Description: Context: Trade (complex type), Contract (complex type) Derivation rule: At least one of documentation/contractualDefinition element and documentation/masterConfirmation/masterConfirmationType element exists and contains the string "ISDA1999Credit".
XPath description: Context: //element(*, Trade), //element(*, Contract) Derivation rule: some $document in documentation/(contractualDefinitions | masterConfirmation/masterConfirmationType) satisfies contains($document, "ISDA1999Credit") "
#4 They are currently named conditions. I suggest they are named "Definitions" and placed in the rules-functions.xml file, as they are not defined to be specific to CDS.
In summary, these conditions need to be changed so they work when there is more than one Trade or Contract in a message.
06/12/09 7:40 am
I agree that the formulation of the preconditions is a bit weak. It’s probably one of the oldest surviving parts of these documents.
I have no opinion on how to reference the conditions in XPath statements. XPath does not have a sophisticated enough execution model to deal with preconditions efficiently, adoption of some convention would be helpful.
If you are really after definable semantics of how preconditions can work, and want to avoid cases that cause problems when multiple trades are present in an FpML document, the following behaviour adopted by NRL may be of interest.
NRL defines “rules”, which are constraints, and “rule sets”, which are a set of constraints. A rule set comes with an optional pre-condition. If the rule set is violated, the constraints do not execute. Like a rule, a rule set has a “context ” where it applies.
So much for the static definition, now for an operational semantics: it is expected that the rule set pre-conditions are validated first. To do this, a context in the document is found for every rule set – there may be many. If the rule set precondition passes, rules in the rule set are only applied to descendant of the rule set context match location.
In other words: if a rule set applies to a Trade with ISDA1999 rules, the rules in the set would only apply under the element with type Trade. This behaviour will be what you are looking for, unless you have recursive types (which does not happen in FpML).
I have relatively little opinion on how FpML should a) specify operational semantics like this b) express it in the rule documents. Hopefully it will be useful for a discussion! One thing I do suspect is that treating rule sets just like functions will make your life harder.
07/21/09 1:58 pm
Discussed at the VWG. It seemed reasonable but agreed to come back to it after more thoughts from the members.
07/28/09 1:20 pm
Discussed at the VWG. We agreed to wait for Daniel’s thoughts.
07/28/09 1:20 pm
Daniel was at the meeting in the background. We agreed to make a final decision next week.
07/29/09 12:19 pm
I agree with Matthew’s points #1 and #2.
07/29/09 2:28 pm
I agree also on point #3: The rule should work also when there are multiple trades in one message.
We discussed in relation to another issue that perhaps a rule should
have only one context. For consistency, I think that if a rule can have only one context, so should a condition.
In this case the context is “Trade and Contract”. Perhaps Trade and
Contract should have a common abstract base type. I quickly checked the conditions in the various asset classes and I think that all
conditions that use more than one context use Trade and Contract.
About moving the definitions to rules-functions.xml: It’s true that
these conditions are not defined as specifc to CDS products,
but, I’d keep them with the other CDS rules, if they are referenced only by CDS rules. I’d move them to a shared, product-independent
resource file if and when rules for other asset classes need to
08/11/09 1:54 pm
Val WG: ageement to implement Daniel’s note.
03/16/10 6:50 pm
03/29/10 3:19 pm
Update from meeting on 2010-03-23: AJ not present. The task is rolled forward.
04/19/10 4:23 pm
Meeting on 2010-04-13: Action still pending.
08/18/10 11:22 am
Meeting on 2010-08-03: Action still pending.
10/18/10 6:45 pm
Deleted the first two sentences of the “Conditions” section as agreed in # 1 and # 2 (change will be reflected in the next drafts of FpML 4.9 and 5.1)
The Conditions section now starts as:
The context of the rule is NOT carried through to the condition.”
10/18/10 8:11 pm
on #3 need clarification: Let’s take the example of a rule, CD-3b, which uses condition ISDA1999Credit.
the condition ISDA1999Credit is currently defined as:
(context: Trade) (context: Contract) At least one of documentation/contractualDefinition element and documentation/masterConfirmation/masterConfirmationType element exists and contains the string “ISDA1999Credit”.
Context: ContractualTermsSupplement (complex type)
If condition ISDA1999Credit is true, then the content of type must not begin with the string “ISDA2003Credit”.
So if I understand the problem correctly, if an FpML document contained 2
06/25/13 3:51 pm
Try to reformulate rule. Remove formal description. We need to find a way to make it trade-specific. We may need to keep it informal.
ACTION: DD look at the schema and at how the rule could be formulated.
07/15/13 2:49 pm
07/15/13 3:00 pm
I think ISDA1999 and ISDA2003 may be ambiguous. I’d prefer ISDA1999Credit and ISDA2003Credit.
07/16/13 1:57 pm
Marc, I don’t mind. Either is OK for me.
07/16/13 1:58 pm
Needs to be reviewed when more VWG members are present.
07/30/13 2:17 pm
Action for DD: The VWG reviewed DD’s proposal. DD will propose a new formulation referencing ancestor the element of product.
08/19/13 1:30 pm
I uploaded a new file 2013_08_19_CDS_conditions.docx .
The formulation is now OK. Since the validation rules syntax does not support quantifiers, I was able to come up only with the informal rule description.
08/20/13 1:39 pm
We discussed in meeting. The group had no additional feedback.
– DD: seek feedback from AJ.
08/20/13 1:55 pm
Looking at the rule again the xpath formulation can be done with the count() from XPath.
I updated the Word document.
01/24/20 6:44 am
Leave an update
You must be logged in to post an update.