FpML Issues Tracker
closed
Minor
Have not tried
Validation Rules
danieldui
lyteck
Summary
Submitted via email by Dafna Aharonovich
I have a question relating rule col-8:
I find that there is an inconsistency between the English Description and the XPath Description:
To my understanding, according to the English description, the given invalid test case is correct, i.e., invalid
However, according to the Xpath description it is valid, and the example below is invalid, while it should be valid:
col-ex06-MC1-request-margin-template.xml
Both inputs are attached and also can be found in FpML website.
Notes:
danieldui
10/23/12 2:21 pm
A first look at the issue while on the call indicates that the English and the XPath description of the rule are in fact consistent.
The VWG will check the rule and get back to Dafna.
ACTION: DD check the rule. Confirm with Lyteck and AJ.
andrew
10/25/12 6:43 pm
The XPath is missing the @href attributes that hold the actual party references.
Should be:
exposure[1]/exposedPartyReference/@href neq exposure[2]/exposedPartyReference/@href &&
exposure[1]/obligatedPartyReference/@href neq exposure[2]/obligatedPartyReference/@href
So if e[1] is { a, b } then e[2] can be { b, a } but not { a, b }
Do we need a rule that ensures that the same party isn’t taking both roles? (So { a, a } { b, b } would pass col-3 but doesn’t make sense.
We need col-12 (context: Exposure)
exposedPartyReference/@href neq obligatedPartyReference/@href
danieldui
12/17/12 11:48 am
We can ensure that a party does not take both roles with another rule:
Context: HeldCollateral
[exists(holdingPartyReference)][exists(postingPartyReference)]
holdingPartyReference/@href neq postingPartyReference/@href
danieldui
12/17/12 11:50 am
heldCollateral contains three optional elements. Do we need to impose rules no when they should be populated?
danieldui
12/18/12 2:41 pm
ACTION: DD more analysis
danieldui
01/15/13 12:02 pm
Proposed change:
XPath Description:
Context: CollateralBalance
[exists(variationMargin)] [count(heldCollateral) eq 2]
variationMargin/heldCollateral[1]/postingPartyReference/@href neq variationMargin/heldCollateral[2]/holdingPartyReference/@href && variationMargin/heldCollateral[1]/holdingPartyReference/@href neq variationMargin/heldCollateral[2]/postingPartyReference/@href
Question: Is it possible to have two heldCollateral elements but have both postingPartyReference and holdingPartyReference only in one heldCollateral element?
Do we need a more strict precondition? I.e.:
[exists(variationMargin/heldCollateral[1]/holdingPartyReference)]
[exists(variationMargin/heldCollateral[1]/postingPartyReference)]
[exists(variationMargin/heldCollateral[2]/holdingPartyReference)]
[exists(variationMargin/heldCollateral[2]/postingPartyReference)]
danieldui
01/15/13 12:04 pm
We can ensure that a party does not take both roles with another rule:
Proposed new rule col-12:
Context: HeldCollateral
[exists(holdingPartyReference)][exists(postingPartyReference)]
holdingPartyReference/@href neq postingPartyReference/@href
danieldui
01/15/13 12:10 pm
Andrew’s comment is about the element “exposure”. Do we need another issue?
danieldui
01/15/13 2:54 pm
danieldui
01/29/13 3:22 pm
Looking at the schema we did not understand why all the elements in heldCollateral are optional and how this structure is meant to be used.
Lyteck investigated the issue and it looks like the elements are required in the master schema, but are converted to optional in the reporting view. The problem is therefore a bug in the view generation set up, not with the schema or the rule.
ACTION: Lyteck: fix the bug in the rule generation.
ACTION: Lyteck: please provide more details, if needed.
lyteck
01/29/13 3:56 pm
It was an ommission in the masater Collateral subschema (not necessaritly a bug in the conversion scripts) for the HeldCollateral type, added a directive for all children elements
Now, in the reporting view, heldCollateral correctly requires all 3 elements (holdingPartyReference, postingPartyReference, paymentAmount). It can no longer be empty.
lyteck
01/29/13 3:56 pm
It was an ommission in the masater Collateral subschema (not necessaritly a bug in the conversion scripts) for the HeldCollateral type, added a directive for all children elements
Now, in the reporting view, heldCollateral correctly requires all 3 elements (holdingPartyReference, postingPartyReference, paymentAmount). It can no longer be empty.
danieldui
02/26/13 3:01 pm
Lyteck rightly noted that this is not a backwards compatible change, which can not be done at this point.
The group decided to:
1) keep the schema unchanged.
2) create a rule to enforce this constraint (in this issue)
3) create an issue to remove the rule and make the elements required 6.x schema. (issue to be created)
ACTION: DD: Propose draft rule
ACTION: DD: Create new issue