FpML Issues Tracker
closed
Minor
Always
Validation Rules
Admin
danieldui
Summary
FpML FX WG is looking for Valid WG advice on how to restrict the values of a new pointsMultiplier element of type 'PositiveDecimal' to 10^x (1, 0.1, 0.01, 0.001, 0.0001, etc)
Notes:
h_mcallister
07/27/10 9:15 pm
This looks like a good case for using a simple type restricted through application of the ‘xsd:pattern’ facet.
The following schema fragment declares a decimal type restricted to accept (digit) 1, or decimal fractions of the form 0.1, 0.01, 0.001, …
Note that significant digits other than 1, negative values and degenerate forms such as ‘.01’ and ‘0.’ are excluded by definition.
If we wish to restrict the available precision, we can use a declaration like the following:
– this accepts 1, 0.1, 0.01, … , 0.000001, but not 0.0000001 (1e-7)
Of course we could use an enumerated type with the same effect, but patterns are a more concise and direct way of achieving the desired behaviour.
h_mcallister
07/28/10 10:52 am
If pointsMultiplier is optional, how should the message consumer construe the value in absence of the element – presumably a value of 1 (unity) is implied where pointsMultiplier is not specified?
Is it not more straightforward to keep the model as it stands, with forwardPoints supplied simply as a real decimal value e.g. 0.0001 for 1 basis point?
iyermakova
07/28/10 3:29 pm
danieldui
07/28/10 4:16 pm
Tony Coates’ email sent to mailing list on 27 July 2010.
One possibility, instead of a decimal, would be to have an integer (??) element where the integer value indicates how many places to move the decimal point left or right. That would remove any need for any kind of facet. Is that an option, or is this already baked into the Schemas? I don’t know the history.
An enumeration could be applied to. It should be possible to enumerate all of the likely values (and a few more at each end of the range for safety).
Or, two patterns could be applied to the value (in a simple type with two patterns, the two patterns are OR’d together). One pattern would be for values >= 1: 10*
The other pattern would be for values < 1: 0.0*1
danieldui
07/28/10 4:32 pm
I was going to suggest the same xsd:pattern that Harry has posted, if the FX WG wants to keep the schema structure as it is.
I have the feeling that the first pattern is what we want (i.e., “0.0*1”).
The second pattern (i.e., “0.0{0,5}1”) is perhaps too restrictive. Hard-coding the maximum number of decimals allowed usually fires back at some point.
If the schema structure can be changed, I think it would be even better if a the precision could be expressed just with an integer. Which is the first of Tony’s suggestions. Is there a reasonable business term for it?
MarkAddison
07/28/10 4:47 pm
I have re-read the original requirements and want to clarify them.
“FX pointsMultiplier needs to be restricted to 10^x”
If decimals like 0.01 and 0.001 are used should this not be
defined as 10*x
If it is infact 10^x then the values of pointMltiplier are in fact
exponentials -2 and -3 (i.e. 10^-2 and 10^-3)
If it’s the latter I would suggest, assuming this schema is not in use, renaming from pointsMultiplier to exponentialFactor (I’ve never been too hot on nomenclature)
h_mcallister
07/30/10 10:01 am
There is precedent in FpML for using an integer to express the position of the decimal point e.g. in complex type Rounding(roundingDirection, precision), where precision is of type xsd:nonNegativeInteger. For example:
specifies conventional rounding to a precision of 7 decimal places.
However, the appeal of using an explicit points multiplier value is that the message consumer can use it to compute the forward points value directly, avoiding the intermediate step of raising 10 to the nth power to obtain the required factor.
danieldui
08/02/10 10:53 pm
After re-reading the requirement I have changed my mind about using an integer.
I think that in this case it would be counter-intuitive. Am I right to assume that most documents would not contain the optional pointsMultiplier element, which would appear only when a system requires a non-normalised value?
I personally find a bit strange that the FX WG wants to allow the use of non-normalised values. For example, in FpML, a 3% interest rate is represented as 0.03. A system that represents the rate internally as “3” does not have the option to populate an element with a non-normalised value.
iyermakova
08/03/10 12:45 pm
See Andrew Jacobs’ comments below –
“I am not in favour of the scalable approach to FX points being proposed by the FX working group.
Since FpML 3.0 the forward points have been expressed as a decimal value such that rate = spot rate + forward points. For example in FpML 3.0 fx example 3
This is similar to the way in which spreads are expressed in interest rate products, i.e. as a percentage instead of as a number of basis points.
I can see that it would be use full to include some indication of the way that the forward points were originally entered by the trader (e.g. was 0.0040 entered as 4 * 0.001 or 40 * 0.0001) instead of having to code market convention based on currency pairs into the application but I think there is greater value in having the forward points value consistently represented regardless of the multiplier. This approach also makes it easier to convert between legacy message formats.
I suspect expressing the value of a point as a decimal restricted by the pattern ‘(0.0*)?1’ or is easier to understand than an (negative) integer power of 10. Personally I’d just include it as an optional element after then forward points instead of a nested structure. Something like…
Andrew Jacobs
”
danieldui
08/18/10 1:18 am
Added updated version of the doc file.
The FX WG accepted Andrew Jacob’s proposal.
The FX WG clarified their requirement, which made comments other than about the use of xsd:pattern not relevant.
danieldui
08/18/10 1:19 am
FX WG OK with AJ’s proposal.