Standardize recommended formats for 'primitive' Context fields

[kriswest]

Enhancement Request

Add recommended formats (SHOULD) for common field types to the Context specification, where those fields don't (or don't often or always) warrant a full embedded context type. Those field types should reference external standards where possible.

Note recommending a format for fields of these types doesn't preclude them also having a context type. However, if it is decided that they should always be full context types then that should instead be required in the standard and this information distributed amongst each individual type.

Use-case

Providing recommended formats will reduce or prevent competing conventions from being established in both standardized types and in-house types created by app developers - helping to ensure applications can interoperate through FDC3 more reliably.

Further, conversion of a format or code is often trivial if the target format is specified and it can be validated by a schema. Whereas interpretation of diverse formats from a single field can be far more difficult as is validation via a schema.

Examples

For example, the following types of data might have a recommended format:

• Time
  • ISO 8601-1:2019 (already linked to in References page)
  • A timezone indicator should be included
  • E.g.
    • Time in UTC: 2022-03-30T15:44:44Z
    • Also time in UTC: 2022-03-30T15:44:44+00:00
    • Same time in EDT: 2022-03-30T11:44:44-04:00
  • Parsing in Javascript: let aDate = new Date("2022-03-30T11:44:44-04:00")
• Date
  • YYYY-MM-DD date format from ISO 8601-1:2019 (already linked to in References page)
    • E.g. 2022-03-30
    • Parsing in Javascript: let aDate = new Date("2022-03-30")
• Country code
  • Alpha-2-code from ISO 3166-1 (already linked to in References page)
    • Note current fdc3.Country type uses both the Alpha-2 and Alpha-3 codes - picking one would simplify requirements
  • E.g. GB or UA
• Currency code
  • Alphabetic code from ISO 4217 (needs adding to References page)
  • E.g. GBP or UAH

[pauldyson]

These look good to me. Very happy to see the use of ISO standards for time and date and an instance on TZ indicator ... our system supports users working across multiple locales on a platform that treats TZ optionally and it is a right pain I can tell you!

On country codes, whilst I agree picking the Alpha-2 codes would simplify requirements, however I think the reality is we'll have to deal with a mix; just integrating with all of Bloomberg, Refinitiv, Factset and IHS (plus a few smaller data providers) means we have to convert but Alpha-2 is definitely the more prevalent.

[nemery-flextrade]

+1 to Paul's comment with regards to multiple timezones - algo orders often have start/end time parameters and being able to clearly indicate if they are in traders local time versus exchange time would be lovely.

Potential issue on the currency code front - ISO4217 does not (as far as I can see) include a provision for dealing with minor currencies.

[nemery-flextrade]

+1 to Paul's comment with regards to multiple timezones - algo orders often have start/end time parameters and being able to clearly indicate if they are in traders local time versus exchange time would be lovely.

Potential issue on the currency code front - ISO4217 does not (as far as I can see) include a provision for dealing with minor currencies.

Just commenting here for direct reference, I believe the consensus was that we expect only major currency to be communicated on the wire, conversions to minor currency should be the responsibility of the consuming system (where required)