FpML Issues Tracker
closed
Minor
Always
Validation Rules
Admin
None
Summary
The Reference Rules are wordier than the Rules Specification directs us. The form of the the rules could be shrunk.
The rule today: " ref-1 (Mandatory) Context: AssetReference (complex type) The @href attribute = the @id attribute of an element of type Asset. "
First proposed form: " ref-1 (Mandatory) Context: AssetReference (complex type) @href = Asset (complex type)/@id. "
There is a problem with the way we write something is a type in FpML. This form of "xyz (complex type)" doesn't allow us to easily put these into XPath.
Second proposed form: " ref-1 (Mandatory) Context: AssetReference (complex type) id(@href) instance of element(*, Asset) "
This uses the XPath id() function to find what the id resolves to.
Notes:
iyermakova
09/16/08 2:21 pm
Reviewed by Val WG on 16-SEP-2008: Agreed to raise this for discussion when Matthew Rawlings is on the call.
matthewdr
12/09/08 2:35 pm
Agreed at the VWG for ISDA (Lyteck), to implement for the precise description.
lyteck
12/09/08 10:17 pm
will go ahead with implementation, but ref-18 seem to implement a different syntax (see issue 830):
ref-18
Context: PricingStructurePoint (complex type)
[exists(underlyingAsset)]
every $generic in coordinate/generic satisfies id($generic/@href) is underlyingAsset
Should we reformulate ref-18 as?
ref-18
Context: PricingStructurePoint (complex type)
[exists(underlyingAsset)]
id(coordinate/generic/@href) instance of element(*, underlyingAsset)
matthewdr
12/10/08 9:36 am
ref-18 is different because “coordinate” is a repeating element. It says this in the text of issue 830, where it explains why the “every $x in satisfies” clause is used.
lyteck
12/10/08 7:25 pm
implemented using template:
“id($context/@href) instance of element(*, XYZComplexType)”