FpML Issues Tracker
closed
Minor
Always
Equity Derivatives
Admin
apparry
Summary
A rule is needed to prevent circular references in relative notionals.
An example failure scenario of a notional reference being circular is a notional referring to itself.
In general a new rule is needed. The rule would prohibit circular references within notionals. This is expressed with a function because this is the simplest way to express the recursion through notionals.
" eqd-xx (Mandatory) Context: ReturnSwapNotional (complex type) Rule: circularNotionalReference(.) Comment: Notional references must not be circular. "
" Function Name = circularNotionalReference Description = This function tests if a //element(*, ReturnSwapNotional)/amountRelativeTo/href points back to itself in a circular reference. A circular reference is schema legal but not FpML legal. The parameter is a set of Return Swap Notionals. IIf the Notional is a leaf the result is false, otherwise the reference is descended recursively.
Parameter 1 = $notionals as element(*, ReturnSwapNotional) (min=1, max=unbounded) Result = xs:boolean (min=1, max=1) Test = If exists($notionals[last()]/(determinationMethod|notionalAmount)) return xs:boolean("false"), else if $notionals[last()]/id(amountRelativeTo/@href) = $notionals return true, else return $notionals | $notionals[last()]/id(amountRelativeTo/@href) "
A far simpler, and preferred alternative would be to have the href reference determinationMethod or notionalAmount, rather than their parent. This would use schema structure to preclude any circularity.
A different type of reference should be used so each reference is to one type and we have typed references.
That would change the schema to:
Notes:
matthewdr
10/20/08 10:04 am
“Jim Brous”
Sent by: eqdwg@fpml.org
17/10/2008 14:31
Please respond to
eqdwg@isda-fpmlweb01.ops.servervault.com
To
cc
Subject
FpML-EQD Preventing a circular reference in relative notionals
A comment on issue discussed at today’s meeting, Preventing a circular
reference in relative notionals, http://www.fpml.org/issues/view.php?id=860
The schema change proposed in the issue log uses elements with type IDREF,
such as
Some XML validation engines will not allow an element to be of type IDREF.
It would be better to use type Reference, which uses an href attribute.
This approach will validate correctly and is more consistent with FpML.
Regards,
Jim
Jim Brous
Managing Partner
Metro Solutions LLC
917.593.4195
jbrous@metrosolutions.com
http://www.metrosolutions.com
matthewdr
10/20/08 10:30 am
Based on Jim’s feedback I would like to revise the proposal.
I can well believe some validation engines do not support elements of type IDREF. I suggest we use an attribute of type IDREF instead.
Out of interest which engines don’t support IDREF in elements?
My revised proposal is to use an attribute of type IDREF. We should not use the Complex Type Reference because it is deprecated as it is untyped – i.e. it can refer to anything.
A new complex type that refers to notional is needed.
Reference to a calculation period dates component.
iyermakova
10/31/08 5:59 pm
iyermakova
11/04/08 2:53 pm