FpML Issues Tracker

642: Interval can be expressed with fewer rules

March 7, 2008

closed

Minor

Always

Validation Rules

Admin

None

Summary

This is a proposal to express Interval more clearly and succinctly.

# Current structure Today the Complex Type Interval is expressed as a sequence of periodMultiplier and period. This requires two rules: Rule 1: If the periodMultiplier is zero, then the period must have the value "D". Rule 2: If the period has the value "T" then the multiplier must be 1.

The rules for the current structure are missing and must be added to the Validation Rules if we keep the current structure.

A type defining a time interval or offset, e.g. one day, three months. Used for specifying frequencies at which events occur, the tenor of a floating rate or an offset relative to another date. A time period multiplier, e.g. 1, 2 or 3 etc. A negative value can be used when specifying an offset relative to another date, e.g. -2 days. If the period value is T (Term) then periodMultiplier must contain the value 1. A time period, e.g. a day, week, month, year or term of the stream. If the periodMultiplier value is 0 (zero) then period must contain the value D (day).

# Proposal to use a union with duration. A simpler structure, would be to form Interval from a union of xsd:duration and the NMTOKEN "P1T". This would eliminate the second rule, and make most usages of Interval typed as a xsd:duration for simpler processing.

A type defining a time interval or offset, e.g. one day, three months. Used for specifying frequencies at which events occur, the tenor of a floating rate or an offset relative to another date.

# Proposal to use a choice of a duration or a term. This would also elminate the second rule. A type defining a time interval or offset, e.g. one day, three months. Used for specifying frequencies at which events occur, the tenor of a floating rate or an offset relative to another date. The Interval is the term between Effective Date and Termination Date

# Question - is the first rule necessary? Why must I say "P0D" and not "P0Y"?

# Action Required - Whether we choose a proposal or an existing structure we will need to implement the rules for whatever we choose.

Notes:

  • matthewdr

    05/30/08 3:41 pm

    Agreed at the MTF on the 30th May 2008 to keep the current structure and implement rule 1 and rule 2 in the FpML Validation Rules, and assign to the VWG.


    shared-25 (Mandatory)
    Context: Interval(complex type) [periodMultiplier = 0]
    Rule: period = “D”
    Comment: A zero length duration must be described as zero days.

    shared-26 (Mandatory)
    Context: Interval(complex type) [period = “T”]
    Rule: multiplier = 1
    Comment: A term duration must be one term in length.

  • h_mcallister

    06/03/08 6:04 pm

    # Question – is the first rule necessary? Why must I say “P0D” and not “P0Y”?

    The answer lies in recognising that the current usage of the Interval type conflates two concepts i.e. frequency (period, tenor) and duration (offset).

    For a frequency, periodMultiplier cannot be zero (or negative), whereas this is possible for a duration.

    The only context in which periodMultiplier=0 is legitimate is the case of a zero duration offset, typically (but not exclusively) denominated in days.
    An example of an offset not denominated in days occurs in the inflationRateCalculation, where inflationLag is expressed as a number of months (typically, 3M).
    Market practice means that a 0M inflationLag should never be produced – but is this sufficient justification for the requirement that period must be D where the multiplier is zero?

    We can dispense with Rule 1 by an adaptation in schema. Two changes would be required:
    (1) change the type of Interval/periodMultiplier, to positiveInteger. This re-defined Interval will be used in all contexts where Interval is currently used to represent a frequency or recurring period.
    (2) create a new type “Duration” with content (periodMultiplier, period) where periodMultiplier is of type (signed) integer, as for the current Interval.
    This type will replace Interval in contexts where Interval is currently used to represent an offset or non-recurring duration, and will be the new base-type for Offset (and by extension, RelativeDateOffset).

    (Alternatively, retain the current Interval type for the “Offset” contexts, and create a new type “Frequency” with strictly positive periodMultiplier for use in the “frequency” contexts; the effect is the same).

    This schema change is neutral for all valid instance documents, but has the advantage of forcing a rigorous distinction between the different uses of Interval. Under the adapted schema, we don’t need a rule to enforce the association of zero multiplier with period “D”, because the context will determine whether this is appropriate.

  • h_mcallister

    06/05/08 9:23 am

    The value domain of ‘period’ differs slightly across the usages of Interval: T[erm] is required in the “frequency” context, but is meaningless as an offset.

    Therefore we require distinct enumerations for period in the “Frequency” and “Duration” types. In an informal notation:

    Frequency/period = {D,W,M,Y,T}
    Duration/period = {D,W,M,Y}

  • matthewdr

    09/12/08 10:40 pm

    I suggest we go with Harry’s first proposal.

  • matthewdr

    12/09/08 2:42 pm

    Agreed at the VWG to implement Harry’s proposal – all his proposed changes. Agreed Marc Gratacos will inform the Coord committee.

  • matthewdr

    02/02/09 12:26 pm

    The solution to issue #910 depends upon this. What progress is there?

  • matthew

    02/02/09 7:58 pm

    Marc Gratacos presented this today to the Coord committee. Consenus was reached to implement Harry’s first proposal plus making the two enumerations distinct.

  • matthewdr

    05/11/09 12:46 pm

  • h_mcallister

    05/18/09 10:30 am

    (1) Is the type name “Offset” intended to refer to the existing FpML type, having content (periodMultiplier, period, dayType?)?
    – if so then the introduction of the dayType element into Frequency is incoherent.

    Otherwise, what is the intended definition of Offset?

    (2) Please clarify how views on the use of “union” have changed (allegedly).

    Is the intention of this proposal to flatten the Interval type (or its derivatives) into a simple type formed by concatenation of periodMultiplier & period?

  • matthew

    05/18/09 11:09 am

    A1) The term “Offset” comes form Marc Gratacos’ proposal that we were discussing. From Marc’s usage I can see this is definitely not the existing type of the same name. To go forwards this will need its own name.

    A2) The revised schema I provided is incorrect and that it unions a Complex Type and the value “P1T”. Just an error.

    I will update the proposal to correct it.

  • h_mcallister

    05/21/09 4:33 pm

    For reasons of precision, and to avoid confusion with any existing FpML type, I used the terms “Frequency and “Duration” in my original proposal – please see my posts above (0001547, 0001556).

  • matthewdr

    06/09/09 1:26 pm

    Discussed at the VWG. Agreed to implement as an xs:union with the xs:token(“P1T”).

  • Leave an update

    You must be logged in to post an update.