[DO NOT MERGE - to be superceded] 442 Define more context types used to visualize (or otherwise represent) financial data

[kriswest]

resolves #442
Adds Chart, Currency, DateRange, Indicator, Trade and Valuation context types to the standardized set and enhances Position to better represent data commonly associated with Positions.

Submitted on behalf of the ChartIQ development team (@rbruckheimer)

[kriswest]

PR comments from an anonymous contributor and responses from me (@kriswest):

Is there a naming convention for context keys?

Only this:

Where an identifier is the name of an existing standard, external to FDC3, it is represented in all caps.

https://fdc3.finos.org/docs/context/spec#identifiers

Country
Should we mention ISONUMERIC as an alternate ID?

As in ISO 3166-1 numeric? As opposed to alpha-2 and alpha-3? If you think it's often used... I assume using a field name like ISONUMERIC. However, as these are pretty easy to convert (e.g. with https://www.npmjs.com/package/i18n-iso-countries ) I would be tempted to err on the opinionated side. At the end of the day the more variation that's encouraged, the harder it will be to be compatible with other applications using the standard. Hence, perhaps it's even worth encouraging a particular code (2 or 3 characters).

N.B. this PR just moved the Country type into alphabetical order and didn't change it. Hence, if this change were applied it would need to go in a new issue/PR.

Currency
There is an ISO for currency (ISO 4217) should we use that in an id object in a similar fashion to Country?

Absolutely. This PR is I think using the ISO 3 character codes, but hasn't identified that (and named the field ISOCODE rather than code). I'll update the PR for that.

DateRange
Do we need a Date as well as a DateRange - or is there a better approach that can combine both – or is the assumption that a DateRange with just a starttime is effectively a Date?

We probably do need a basic date type AND datetime... its reasonable to think someone might want to send a single date as context. This is probably a good point to bring up in the discussion of primitive types. If we create a Date and/or DateTime type do we recommend they are used (full object with a type field) OR do we allow for (any primitive type that we add to the standard) to be used as a normal field? I feel like DateRange might be a bit cumbersome if composed of two embedded DateTime context objects:

as proposed now:

{
    "type": "fdc3.dateRange",
    "starttime": "2020-09-01T08:00:00.000Z",
    "endtime": "2020-10-31T08:00:00.000Z"
}

if composed of date types:

{
    "type": "fdc3.dateRange",
    "starttime": {
        "type": "fdc3.dateTime",
        "ISODATETIME": "2020-09-01T08:00:00.000Z"
    },
    "endtime": {
        "type": "fdc3.dateTime",
        "ISODATETIME": "2020-10-31T08:00:00.000Z"
    }
}

but I've seen worse... it also allows us to acknowledge the ISO standard (ISO 8601) behind the date time format - although the Context spec could also define conventions for certain 'primitive types' and do so there.

[hampshan]

I agree with the points about requiring to agree primitive data types. I think date and datetime particularly need to be defined.

I was also wondering whether it would be helpful to further define date/datetime ranges and instants too.

Regarding charting data, I wondered whether it would be helpful to define a more generic data structure to pass series/grid-like data to other apps that support charting, grids, or used for calculations, etc.

[kriswest]

Superceded by #715, #706