Standardize a context type representing a Chart

[kriswest]

Enhancement Request

Create a context type representing details of a Chart, which may be used to request plotting of a particular chart or to otherwise share details of its composition.

Supercedes issue

• Define more context types used to visualize (or otherwise represent) financial data #442

Use Case:

FDC3 already defines a ViewChart intent, which is typically provided with a basic Instrument context as input. This represents the bare minimum data needed to plot, for example, a pricing chart. However, there are many use-cases for more complex inputs to Charting application, such as:

• A list of instruments for comparison
• The time period to plot the chart over
• The style of chart (line, bar, mountain, candle etc.)
• Other settings such as indicators to calculate, or data representing drawings and annotations

Further, a charting application may wish to output a context representing what it is currently displaying so that it can be recorded by another application

Intents

ViewChart

(as defined in the standard already)

Contexts

Chart

Represents the configuration of a Chart to be or that has been plotted.

Details

Property	Type	Required	Example Value
type	string	Yes	'fdc3.chart'
instruments	InstrumentList	Yes	[   {     "type": "fdc3.instrument",     "id": {       "ticker": "AAPL"     }   },   {     "type": "fdc3.instrument",     "id": {       "ticker": "MSFT"     }   } ]
range	TimeRange *	No	{   "type": "fdc3.timeRange",   "starttime": "2022-03-30T15:44:44+00:00",   "endtime": "2022-04-30T23:59:59+00:00" }
style	string	No	'line' | 'bar' | 'stacked-bar' | 'mountain' | 'candle' | 'pie'
otherConfig	object **	No	{ /* undefined object used to contain unstandardized config */}

* See issue:

• Standardize a context type representing a range of time: TimeRange #646
  ** It is very common for charts to support other configurations, such as indicators, annotations etc., that a charting application may wish to take as input or produce as output, allowing the chart to fully configured and/or reproduced accurately.

Example

const chart = {
    type: "fdc3.chart",
    instruments: [
        {
            type: "fdc3.instrument",
            id: {
                ticker: "AAPL"
            }
        },
        {
            type: "fdc3.instrument",
            id: {
                ticker: "GOOG"
            }
        }
    ],
    range: {
        type: "fdc3.timeRange",
        starttime: "2020-09-01T08:00:00.000Z",
        endtime: "2020-10-31T08:00:00.000Z"
    },
    style: "line",
    otherConfig: {
      indicators: [
          {
              name: "ma",
              parameters: {
                  period: 14,
                  type: "ema"
              }
          },
          {
              name: "volume"
          }
      ]
    }
};

fdc3.raiseIntent("ViewChart", chart)

Additional Information

The original version of this issue (#442) and its associated PR (#443) included the specification of an Indicator type, which are a key component of modern technical charts. As pushback was received on this element, it has been removed in favour of the otherConfig element, whose content is unstandardized, allowing applications that require this information to accurately reproduce a chart to still include it in this context.

[kriswest]

Preview url: https://deploy-preview-715--lambent-kulfi-cf51a7.netlify.app/docs/next/context/ref/chart

[robmoffat]

Ok, I have a couple of questions/issues around this, which hopefully you can answer.

My understanding is that the ViewChart intent is there to allow a App A (say a blotter) to request another app (App B) to show a chart. However, it seems like there is a separation of concerns issue:

• App A knows about instruments, markets and tickers
• App B knows about charts and data layout.

it seems like the context data in this case is just the list of instruments, and would be known by App A. However, all the rest of the data would have to be worked out by App B as a result of the request (maybe they are controls on the app to decide how it looks / range / scale etc).

Otherwise, App A now has to understand the other concerns of all the possible apps that are going to potentially use this data.

[kriswest]

A list of one or more instruments is pretty much the bare minimum for plotting a chart. If we're talking about financial/pricing charts it's not unreasonable to assume further details including range and plot type (style). We (in this case, ChartIQ) also think indicators are pretty fundamental to technical analysis charts, but agreed to draw those back to otherConfig as standardizing 120+ indicator names is going to be tough. There's a lot more that could go in there (static data, annotations and drawings etc..).

However, its also worth noting the ViewChart isn't the sole use case for this context. We and other have demoed the state of a chart being output and shared (e.g. sent through a Symphony chat to be plotted elsewhere, a Factset chart being sent to the Factset notes app to be preserved etc.). By using the context rather than a flat image, a real interactive chart can be plotted at the other end (perhaps via ViewChart, perhaps via other logic), and perhaps by a different app/configuration that does a different anysis, overlays trades or TCA data etc..

In short, there's a lot we can do if we can make some small assumptions about charts.

[kriswest]

We had a further chat about this off to the side:

@robmoffat:

In App A (a list of stocks, say, or a news article), you have some context data - say, 2 or 3 instruments.. The agent then needs to determine which intents are appropriate for that context data.. so ViewChart is one of them. But App A shouldn't have to know about what the graph looks like, whether it's a bar graph or a candle graph or a scatter plot, correlation or whatever. That data is the concern of the charting app... no?

Well... those fields are optional (where instruments isn't), so it doesn't have to know, but it might. This is particular relevant in those cases where you are looking to reproduce a specific chart.

Charting engines can often plot data relating to the same underlying entities in very different ways, e.g. For a set of instruments, I might want a scatterplot of trades (against time), a heatmap of trading activity, or a pricing chart (candle/mountain/line). These might be different chart applications OR they might be different styles in the same application.

The current lack of a chart type severely limits our options for what we can be requested via ViewChart, but also prevents the chart state reproduction use case without a proprietary type (for something that can be modelled independently of the particular charting application).

[robmoffat]

I can see what you are saying about reproducing a chart. However, that's a very different use-case from the one in the original description.

And, it would only be useful if you were wanting to reproduce a chart in a totally different charting app: if it were the same charting app, then it would be better off using it's own home-grown Chart context-data object, which would probably be honed to exactly the requirements of that app.

A (possibly) better use-case for having the Chart context would be so that other apps could add their intents to it, or listen to the changes to a chart on a channel. But I'm struggling to think of an example of where that might be useful though.

[robmoffat]

What this does make me wonder (again, caveat the fact I am very new to this project and may have missed something painfully obvious to the more experienced hands) is shouldn't FDC3 have an API for storing configuration/preferences for each app?

In VSCode, for example, each installed plugin can contribute settings pages to the overall settings manager, and also retrieve its settings information.

This would be helpful in the above use case, as this part of the config could be held in app-specific settings:

    style: "line",
    otherConfig: {
      indicators: [
          {
              name: "ma",
              parameters: {
                  period: 14,
                  type: "ema"
              }
          },
          {
              name: "volume"
          }
      ]
    }

When the intent to ViewChart is then called, the context will be the InstrumentList and the other defaults can be loaded from the DesktopAgent.

Maybe something to consider for 2.x > 0

[kriswest]

Hey @robmoffat, charts have different use cases that can often be handled in a single application with different settings. Being able to receive these means the chart can be driven by other applications. Further, if some defaults were saved (which ChartIQ and other apps can do internally anyway) then having the optional parameters would allow override of them (e.g. to reproduce a specific chart or to produce a specific type of chart on demand). Remoing the parameters and relying on defaults/preferences alone is definitely limiting into terms of interoperability and might result in duplication (if/when we have to introduce a different type to represent the state of a chart, rather than a request for it).

Regarding saving settings... do we do it at the app-level (preferences) or the instance level (workspace state)? The latter is essentially this issue: #386 (raised by @lspiro-Tick42), which several of us have expressed interest in, but have yet to work on proposals for. Each of the container vendors has a proprietary approach to some form of workspace state (and in our case also to preferences). However, please note this comment in the API overview:

The role of FDC3 API specification is to establish a baseline interface for interoperability between applications. Because FDC3 is largely an agreement between existing platforms and applications - standards should be optimized for ease of adoption rather than functional completeness. Functionality absent from a FDC3 specification is in no way a commentary on its importance.

That comes from the first version of FDC3, but well describes the ethos of early work on FDC3, which was solely focused on app-to-app interop, rather than app-to-desktop. Personally, I see advantages to opening up FDC3 to more of the issues of an app integrating into a container/desktop agent as that is a key part of the apps working together (workspace state, persisting prefs, notifications, window size/position defaults etc.). I think that's something we would have to agree through a resolution of the Standards Working Group and some clarifying changes to our charter and scope.