The architecture document should clarify whether it is permitted to require content must be in a specific order or sequence. For exmaple eqd-7 “The elements in bermudanExerciseDates/date should be in order, earliest date first.” Is this type of rule permitted in the schema? This cannot be specified in a schema, and can only be added … Continued
http://www.fpml.org/spec/2007/wd-fpml-4-3-2007-07-30/html/fpml-4-3-intro.html#s3.1.2 “In practise enterprise message buses cannot be expected to halt the enterprise to preserver sequence. Hence this is not a requirement of FpML.” “preserve” is mis-spelt “preserver”.
For example valid-eqd-7-01.xml should change the content from: 2002-04-21-00:00 2002-05-21-00:00 2002-06-21-00:00 To: 2002-04-21-00:00Z 2002-05-21-00:00Z 2002-06-21-00:00Z For the path /FpML/trade/equityOption/equityExercise/equityBermudaExercise/bermudaExerciseDates/date
Add a recommendation to the architecture to use XPath 2 order for date sorting in FpML. This is necessary because of rules such as eqd-7, which require the data to be sorted: “eqd-7 (Mandatory) The elements in bermudanExerciseDates/date should be in order, earliest date first.”
eqd-7 states: “eqd-7 (Mandatory) The elements in bermudanExerciseDates/date should be in order, earliest date first. ” Is this ascending or descending order? Presumably it is the order defined by the default collation in XPath 2 for dates, and not strings?
eqd-7 refers to bermudanExerciseDates which is an element not in the schema. What is in the schema is: /FpML/trade/equityOption/equityExercise/equityBermudaExercise/bermudaExerciseDates eqd-7 should be changed to use the term “bermudaExerciseDates”.
eqd-4 states: “Context: EquityBermudanExercise (complex type) eqd-4 (Mandatory) commencementDate/adjustableDate/unadjustedDate must be ../../../tradeHeader/tradeDate. ” I read “must be” as “is” – i.e. not equivalent, but identical. This would be a nonsense so I presume there is a missing comparison operator. Should it not be “>” or “>=”? http://www.fpml.org/spec/2007/wd-fpml-4-3-2007-07-30/html/validation-rules/rules-english-eqd.html
The schema refers to “EquityBermudaExercise”. This is incorrect. For example we have EquityAmericanExercise and not EquityAmericaExercise, and EquityAsianExercise and not EquityAsiaExercise. The adjectival form of Bermuda is Bermudian or Bermudan. Bermudian is the self-designation and should be preferred.
eqd-4 states: “Context: EquityBermudanExercise (complex type)” This is incorrect. The additional “n” in “Bermudan” is an error. It should be: “Context: EquityBermudaExercise (complex type)”
There is a problem today with some of the validation rules – they define a narrow context and then test constraints on elements that are out of scope for that context. For example, take eqd-1: ” Context: EquityAmericanExercise (complex type). commencementDate/adjustableDate/unadjustedDate must be equal to ../../../tradeHeader/tradeDate” The problem with this is that tradeHeader/tradeDate is out … Continued