FpML Issues Tracker
closed
Minor
Always
Architecture
Admin
andrew
Summary
Rules shared-5 requires that the payerPartyReference and receiverPartyReference be disjoint. This is to ensure the payer and receiver are disjoint.
The problem is this rule falsely assumes that any two parties are always disjoint. There is nothing in the schema or Architecture to require two parties to be disjoint. In practise I am seeing messages where a Party is listed more than once. It may or may not have a common PartyId across both Party entries. Especially where a Party plays more than one role, it may be listed more than once.
Context: payerPartyReference shared-5 (Mandatory) If ../receiverPartyReference exists, then the @href attributes of the two elements must not be equal.
If the Parties are to be disjoint, then it must be stated in the Architecture clearly that all elements are required to be disjoint in all sets, or it must state specifically in the schema that the Parties are disjoint.
XML says nothing about whether the things represented by the elements are disjoint or not. The comment from Henry Thompson (one of the primary authors of XML), was to the effect that you must state explicitly how you interpret the XML.
The sort of thing I am seeing is (anonymized):
Party 1 and Party 2 are the same legal entity.
Notes:
matthewdr
02/22/08 7:32 pm
AJ said in the AWG on 21/Feb/2008 that FpML XSD “has OO semantics”. We just now need to establish which OO semantics and to add that to the Manual or Architecture so users can abide by that.
matthewdr
02/28/08 6:03 pm
I propose we add CMOF OO semantics. These are public and well defined.
matthew
03/14/08 7:42 am
That is I propose we add semantic equivalent to CMOF, or explicitly reference CMOF, but we don’t want to do a folksy redefinition of CMOF.
matthewdr
04/03/08 1:28 pm
We agreed at the AWG the general solution is to agree to add a definition of disjointness.
“Elements in FpML have identity. Each element definition represents as disjoint concept, just like an object in OOP. For example for a Portfolio containing Positions FpML requires the positions to be different positions – i.e. they are disjoint.”
matthewdr
05/15/08 1:16 pm
Discussed at AWG on 15th May as part of the “Modelling Guidelines” paper discussion. The resolution was Andrew Jacobs will work the agreed text into the paper.
andrew
10/02/08 10:28 am