Tim Kolecke

Tim Kolecke

Tim Kolecke

Meeting started with discussion of the Pull Request based on the presentation in the previous week’s meeting from Johann, Espen and Riko.

Tim noted that there is often disscussion about the line between Context Data and Financial Objects and asked the group to keep a focus on the schema itself. Where appropriate we can talk about how FO fits into the schema and how we communicate this to other places on the desktop as that’s what context data specification is about - providing a means for interoperability on the desktop.

Comments/discussion on PR #8  included:

• Aim is to ensure that the schema will work for the lowest common denominator set of uses cases identified.
• The object in discussion is the Context Object and only change is that type is prefaced with a $, which is normal in JS and JSON.

• Tristan queried why the $ and Riko said it was to address concerns about other objects already using a property called type so was intended as a disambiguation and to also improve searching. An alternative was to use property type or called Context type or FDC3 type so this was to provide an easy way to identify that this is specific to FDC3. This could be included in data payload but that has been removed.
• Quick recap on presentation from last week:
• There were multiple type properties in the old envelope, object at top, definition, which was the URL and there was the type inside data payload.
• Other major change is that there is no longer a data array. Instead of using an array you use an object with as many properties as you want within the object (really in JS it is an array with named indexes).
• Discussed feasibility of bulk sending as well, e.g. sending 50 items in one message.
• Dropping the envelope also means losing version and multiple approaches to handling version was discussed. (In FIX for example, you version the protocol)
• Discussion around why there is no FDC3.type in this first version. Leslie suggested moving everything except Context into examples. Include a comment in the examples to say that in future the group may go on to specify the FDC3 instrument, for example. The group agreed.
• You’ll know from the API that you are receiving a context event and focus here is the content within context.
• Three things you can do with a context: broadcast, invoke intent,
• Group agreed to drop versioning for this release and it can be addressed in a later version.

Riko asked if there were any other blockers to ratifying the ContextData spec and also asked whether they should have a type registry so there is an easy way to reference or collaborate around types. FINOS (Maurizio Pillitu and Rob) are working on standardizing this as part of the overall documentation standardization.

• Leslie flagged a point on slide 10, which is that context can hold multiple types and asked about child contexts and the implication of a tree search. Ben commented that this is tricky because you are trying to guess and pattern match the object. Also potential performance implications. Espen noted that the subtypes allow you to traverse the object.
• Ongoing disucssion about how types are discoverable.

• Tristan raised one last thing: the ID field uses simple key value pairs and they might need something a bit more complex, e.g. string to number or nested ID, for example at Wellington they have “string | number | { [compositeIdName: string]: string | number | null };” This allows compound identifiers, to pass a holding, for example.
• Here is an example of how you could potentially do it (holding example):

• Agree as a group to use string only for now but suggested adding a PR that, for example, ID should also include numbers.
• No other blockers to ratify the ContextData object and the specification.

Tim Kolecke