FpML Issues Tracker
closed
Minor
Have not tried
Validation Rules
danieldui
lyteck
Summary
Email from Lyteck:
Request from the BPWG/RPTWG to develop a new messaging rule to handle the Multiplicity of the onBehalfOf field the BPWG evaluated and approved a request from the RPTWG to allow multiple on-behalf-of elements in a message to an SDR.
We wrote down an action to ask the VALWG.
- >> We discussed developing a validation rule (e.g., A maximum of 4 onBehalfOf elements should only occur in novation flows. In other cases the number of fields should at most be 2).
- The BPWG agreed to increase the cardinality of onBehalfOf from 0..1 to 0..4 globally for all the messages in 5.3 WD1 (The draft should be available for review by the Coordination Committee by the end of September). Up to 4 parties may be involved in a transaction, in the case of a novation.
- In 5.2 and earlier, the field is currently used in the following message types: ResponseMessage, NotificationMessage, NonCorrectableRequestMessage, CorrectableRequestMessage, CorrectableRequestMessageMediated
- Background: This topic had been discussed at the BPWG forum in the past there were some concerns that making a global change would make the usage of this field unclear. At the time the discussion resulted in a localized change (the multiplicity of the onBehalfOf field was set to 0..2 in select messages of type CorrectableRequestMessageMediated). These original concerns may have been raised at a time where OTC transactions were mainly bilateral. This is gradually changing in the new landscape where SEF, SDR, DCO and other central services may transact on behalf of the parties.
I think we may need two complementary rules (suggested drafts shown below) for further guidance from the VALWG:
msg-5 (Mandatory) English Description: Context: messages that contain onBehalfOf (derived from base types noted above) If the message contains a novation element, the maximum number of onBehalfOf fields must be 4.
msg-6 (Mandatory) English Description: Context: messages that contain onBehalfOf If the message does not contain a novation element, the maximum number of onBehalfOf fields must be 2.
Notes:
danieldui
10/03/11 1:39 pm
Discussed on 20 Sep meeting.
Decided that only rule Msg 6 is needed and should be renamed Msg 5.
ACTION: Lyteck to propose rule formulation.
lyteck
10/04/11 11:07 am
Proposing:
msg-5 (Mandatory)
English Description:
Context: collection()
If onBehalfOf exists, and if novation does not exist, then the maximum number of onBehalfOf elements must be 2.
(Alternatively, a more meaningful description may be: “If the message does not contain a novation element, the maximum number of onBehalfOf elements must be 2.”)
XPath Description:
Context: collection()
[exists(onBehalfOf)] [not(exists(novation))]
count(onBehalfOf) le 2
danieldui
10/05/11 12:08 pm
Discussed on 4 Oct meeting.
Lyteck’s proposed XPath description is OK. We need to go agree on the informal description of the rule.
Andrew J was strongly opposed to this rule and on the schema change that made the multiplicity of “onBehalfOf” 0..4.
Daniel noted that opposing a schema change is not within the remit of the VWG.
ACTION: DD/Lyteck get back to BPWG/RPTWG to ask for examples, which are necessary to create valid/invalid test cases for the rule. Also ask for rationale/minutes of schema change.
mgratacos
10/24/11 10:13 am
Andrew Jacobs (UBS) requested clarification on the earlier decision to increase the cardinality of the onBehalfOf element to 0.4. Members agreed the increase is not needed in the confirmation view. LCH had made a request last year to increase the cardinality to 2 and may be using the few messages affected.
>> The Motion from Andrew Jacobs to revert the cardinality of onBehalfOf in Confirmation view to 0..1 was seconded by Harry/BNPP. We will give LCH the opportunity to respond. We will have a formal vote at the next meeting (Action # 1)
lyteck
10/24/11 8:52 pm
To clarify further:
– In confirmation view, the motion is to change cardinality of onBehalfOf to 0..1 in all messages (including the mediated message, I think requestClearing, changed in 5.1)
– In all other views, the plan is to change onBehalfOf to 0..4 as decided by the bpwg.
This means a validation rule will still be needed. The BPWG will meet 10/28 to discuss the motion. We can still look at the proposed rule for the other views (see suggestion in note added 10/04)
danieldui
10/25/11 1:46 pm
ACTION: Lyteck
– Implement rule and include in all views except confirmation. Keep rule ID to msg-5. Use document() as context.
– Use the following description: “If the message does not contain a novation element, the maximum number of onBehalfOf elements must be 2.” I.e. the 2nd that Lyteck proposed.
Note: Collection() is an Xquery function. Should be documented better?
after…
Implement test cases. Need input from BPWG/RPTWG.
danieldui
11/08/11 2:23 pm
Update from call on 8 Nov: No progress on implementation.
lyteck
11/21/11 10:35 pm
There was a BPWG meeting 11/18 and the group agreed with the proposed implementation from the validation WG.
Brian noted that the rules should be view specific. We already have a mechanism in place that only publishes a set of rules for a particular view (e.g., the collateral rules only appear in the reporting view), however, we may need to enhance the mechanism to work at the rule level (e.g., msg-5 does not to apply to the confirmation view but msg-4 applies to confirmation and other views) >> Lyteck will discuss at the validation WG how to make validation rules view-specific. It would be useful to derive the list of rules that apply to each different view.
lyteck
12/13/11 4:57 am
1. implemented msg-5 as:
(committed in SVN with test case – please check)
2. To make rules view specific, suggesting the addition of the @view attribute within the container: e.g.,
This would require modification to the XSLT to process the @view attribute + modification of batch files to generate a different set of validation rules for each view.
lyteck
01/24/12 12:23 pm
Attached zip contains proposed HTML output for e.g. the confirmation (does not include msg-5) and transparency (includes msg-5) views.
Modified XSLT to create above. not checked in. pending wg approval.
danieldui
01/24/12 4:11 pm
Discussed on 24 Jan call.
The example that Lyteck provided is OK. We had some discussion about how the documentation on various views will look like.
ACTION: Lyteck will commit his script and the source XML files to the repository and show the resulting documentation to the group.
lyteck
02/07/12 8:15 pm
code checked in. An email was also sent February 7 to the mailing list describing the implementation.
danieldui
03/27/12 2:01 pm
The changes that Lyteck made seem OK, but rule msg-5 does not appear in the latest transparency view docs.
ACTION: Lytech to check why msg-5 does not appear in the latest transparency view docs. Fix problem so that the issue can be closed.
mkoli
04/17/12 7:03 pm
Changes have been made to fpml-validation-architecture.xml to allow msg-5 to reappear in the transparency view.Checked in SVN.
mkoli
04/25/12 1:46 pm
updated for FpML-VALID Issue 1071- rule msg-5 does not appear in the latest transparency view docs- corrected changes.4/18/2012