Table of Contents

Date

20 Apr 2017

Attendees

Actions items from previous meetings

• Former user (Deleted) 06 Apr 2017 Based on discussion related to new PresentationML/EntityJSON (MessageML v2), IHS Markit will evaluate the integration of CDS data into FO reference data formats and pricing.  This dataset integrates well with FactSet, so there should be good interoperability to present.  IHS Markit to provide initial timing and approach.
• Former user (Deleted) or Former user (Deleted)06 Apr 2017 Identify target dates for new PresentationML/Entity JSON support (POC to start). 
• Former user (Deleted) If possible, distribute presentation on new Symphony LLC renderer in support of proposed MessageML v2.
• All Members should review and comment on:
  • The Message ML v2 discussion draft
  • The PresentationML draft specification
  • The HTML5 Subset Discussion regarding the PresentationML draft

Agenda

Meeting notes

Frank Tarsillo: Comment at SSF Board Meeting – Frank mentioned participation was low, and feedback from board was that the WG is extremely valuable to their institution because standard formats for financial objects will help them serve clients. Important to understand that there’s a wider community that wants to get involved re: FOs, and this relates to the core purpose of this group, which is to define financial objects. As we talk about specific agenda items, I’d like us to get back to structured data elements and how they can be shared as well as presented. That will help us bring in other institutions. There was a clear mandate from the board to provide “marketing material” that will enable business/product people to understand the work that projects and working groups are doing. That’s something we miss because these conversations are heavily driven by technologists.

Aaron Williamson: Two quick points along that line. I agree with everything Frank just said. I’ve seen a lot of interest from new members in this group in particular and that interest is primarily in standardizing data formats for financial objects. I also looked at the charter and it’s kind of mealy-mouthed about whether defining financial objects is truly a goal of the group, so I wonder if we could state that more clearly.

Bruce Skingle: Agree that defining the structure of data is very important and it’s been frustrating that we’ve been unable to do much of this. Repeatedly asked for people who would participate in a proof of concept or suggest objects that we could standardize most usefully, and there’s been silence. My response is, why isn’t anyone sending representatives to meetings? The entire output of early meetings was about data formats. It was hard work, I did all the talking and nobody else said anything. I’m unhappy with the suggestion that that’s not what we’ve been trying to do.

Paul Teyssier: I’ve been involved in all sorts of innovation patterns and timing is always important. The work initiated a year ago might have been too early because members hadn’t implemented Symphony in their businesses, whereas now appears to be the time to start real business projects. The other reason is that engineers need to be able to put their hands on something to work/iterate on it—there was very little to play with out there, and now there’s a lot more to build upon. I think those two drivers are very important and a reason to turn back to the focus on defining financial objects.

Frank Tarsillo: Bruce, one thing I learned was that we’re not doing a good job across the board of marketing the business aspects of what we’re building. If I showed someone senior at JP Morgan the specifications we’re building, they’d fall asleep. If I showed them a diagram of the use case, a business person at a large banks would say “I need to send engineers to work with that group.”

Paul Teyssier: Suggestion for small group—I think we’re all on the same page, and my belief is that the best way to market use cases is a proof of concept. That should be our first order of business. Do you agree?

Frank Tarsillo: For this meeting I’d like to talk about a CDS POC.

Paul Teyssier: Yes, let’s do that. Is this also the time to engage with the broader community? What are the rpojects you’d like to start in your org? What other projects would be useful to you?

Frank Tarsillo: I agree wholeheartedly, but first we need to give them a base use case to start with.

Bruce Skingle: I agree that we never produce any marketing materials. We had good representation initially, and I felt that the orgs were engaged and that marketing wasn’t necessary, but I can see that you’re right. Maybe we can ping back and forth what we might present.

Frank Tarsillo: And I don’t want to put all the work on you. We should share the load.

Bruce Skingle: I’d be very happy for more contribution, I’m just offering to kick the process off.

Paul Teyssier: I have some ideas that I’ll send to the group and we can iterate. Should we be coordinated in inviting new and old members to join the group?

Bruce Skingle: Let’s move on to the work and come back to that. Frank, do you want to talk about CDS?

Frank Tarsillo: Sure. On our side we’ve started pulling all the reference data, the red data codes we want to associate with the entity model that describes reference data. We’re eager to start applying it, and we’ve created a small database for the purpose. I’m going to create a bot that serves up the reference data appropriately. Johan, I’m assuming you’ll be able to hover over the reference data and click it to enter the FactSet application. How we get or present that data in a conversation, I assume that’s where MessageML 2.0 kicks in, with a hover-over that calls out to the reference data application. I think we should generate a flow diagram of where we’re sourcing the data, what we’re doing with it, and how FactSet is working with it. I think we’ll use ISIN off the back of it. I’m happy to work with someone here on this to create a mockup of what we’d expect to see, then I’ll look at the Entity JSON format and apply the aprticular attributes applicable to CDS reference data, and on the FactSet side, I assume you’ll be able to hover over based on MessageML 2.0 to get what you need.

Bruce Skingle: Can you document this on the Confluence site? There are several object definitions in the old format, I can reformat those, and we can slot this in there. And we can put the flows in there as well. I think we should work in public.

Frank Tarsillo: I would ask to add Hershel Shah to that site to create visuals. But yes, I agree.

Bruce Skingle: Any other questions on CDS?

Johan Sandersson: No, just hit me up whenever you’re ready Frank.

Bruce Skingle: I think next on the agenda is pricing formats.

Frank Tarsillo: We have pricing data along with the CDS reference data, and what I’d like to get to is getting into different object models that provide the content that dealers want to see. I think it’s a separate set of objects and raises a question, Bruce, can we create nested entity objects?

Bruce Skingle: Yes.

Frank Tarsillo: Ok, so pricing and reference could both be tied into the same MessageML objects.

Bruce Skingle: That was always the intent, including with the XML formats, you can see this all on the Confluence site. You have a structured objects that, for example, contains pricing data over time—you can use them to build quite complex structures. The way you’d put pricing data in there is that if you put a price in the object, the hover card could display only that price, but FactSet for example could also show you the current price.

Frank Tarsillo: Hate to bring PresentationML back into the conversation, but if I had a hovercard and wanted to show data that was updating in real time, what would I do?

Bruce Skingle: You’d have an app that’s presented with an iFrame and you’d put the live data in there. We could think about allowing you to write an app in PresentationML, but that gets very tricky. We’ve discussed the implications for content export, etc. The fact that it’s a strict subset of HTML5 and doesn’t support JavaScript is a tough line to cross.

Paul Teyssier: Is that an issue, Frank?

Frank Tarsillo: This is a debatable point, but we should park it for now. I’m still not a fan of the limits on PresentationML, but I’m happy we’re making progress. My viewpoint on it is, it should be a full HTML5 implementation including JavaScript, but that’s just my view. Again, I think we start with the basics, and maybe we can revisit this after we’ve actually worked with PresentationML 2.0.

Bruce Skingle: I’m completely happy with that and I don’t think it’s a discussion for this meeting. But I’m happy to carry it on. We’ve said PresentationML is a strict subset of HTML5, but there’s nothing to stop us from widening it later, including all the way.

Frank Tarsillo: Totally agree. I just think we should focus on a POC right now.

Nick Kolba: Something I’m not clear on is, what is the relationship between PresentationML and Financial Objects Standardization?

Bruce Skingle: They’re conceptually separate things, the reason we’ve been treating them as bound is that, what’s being stored now is markdown, and it’s impossible to put structured objects in that format. In order to get there, we have to change the internal storage format. The two things have been presented in parallel is that implementation constraint, and also that it’s essential that every message contains a default rendering in case your recipient can’t parse the object you’re sending. If PresentationML contained the implementation you needed for each object you send, this wouldn’t be an issue. But as things stand, the default representation has to be a static view. Does that make sense?

Nick Kolba: I feel like there’s a transport problem that’s solvable on a different thread from the objects standardization thread. I understand the need for a default presentation, but there are ways to do that in a loosely coupled way.

Bruce Skingle: It’s not tightly bound, the only relation is that the default representation can provide a financial objects to process separately.

Nick Kolba: Yes, but we’re sending messages that the endpoint of origin is going to encode in a particular way and the other needs to understand it, and that gets negotiated in various ways. So we have a presentation and some data that’s tied to it in some way, but I think there are use cases that are machine-to-machine where all we want to be sending is the objects themselves.

Bruce Skingle: The mandate for this group is to work on situations where there’s at least one human participation, and implementation things like FIX was explicitly excluded in the charter. That’s not what we were asked to do, so the cases you’re concerned with there isn’t within our mandate. In almost every case, the presentation is going to contain something that doesn’t relate to the structured data. Not that you couldn’t do it another way, but that’s not what we’re doing. That said, while what we’ve been talking about is MessageML, what we want to be talking about is taxonomy, formats, and semantics of structured objects.

Paul Teyssier: I think we’re going to call what we’re doing “structured objects” and it will primarily focusing on using the REST endpoints and enabling developers to create renderers within the web client. By and large, it’s almost entirely the spec in Confluence. What we’re discussing is details on CSS implementation, how many styles we’ll offer, etc. Everything else is relatively stable.

Bruce Skingle: What’s the time frame for an early preview?

Paul Teyssier: I’d love to do an end-to-end demo at the next WG meeting in two weeks. I think mid-May is when you’ll be able to use it in your test environments.

Frank Tarsillo: Is there anything we can plug into today? But if it’s mid-May I can wait.

Paul Teyssier: Yes, plus or minus a few days. For everyone else, “Nexus” is a project to give you cutting edge features in your test environments.

Johan Sandersson: One item we discussed at the last meeting—do you have thoughts on what the hovercard would look like without a renderer?

Paul Teyssier: In the initial release, we’ll use the same UI/UX primitives that already exist in Symphony. Only hashtags, cashtags, and people can have hovercards. If you want to extend what’s in the hovercard, there’s a new capability we need to think about, and maybe we can work from Markit’s mockups as a fast-follow.

Johan Sandersson: Cool, I’ll upload my thinking on Frank as we talk about the proof of concept.

Paul Teyssier: It’s clear people want to be able to extend every element of the UX, we just need to think about the order in which we implement that based on customer priorities.

Frank Tarsillo: Question on transports: we have data that needs to be sent to the conversation from somewhere, like a bot. It’s going t o sit on the network. Someone’s going to be typing a cashtag, when someone hovers over that entry, what I’d want to happen is a call-out to the data source, that would provide an MessageML message with everything needed for that hovercard to present that data. How does the transport work to link the hovercard to my data?

Bruce Skingle: That would have to be done with the Extension API. That’s not a feature that’s in the intial release. The way it would work is you’d have to have an app installed, registered to handle that type of entity, so that when the app paints the hovercard, it knows to get the display from that app. If you have several apps installed to handle that data, it will give you the view from the default app, with links to view the others. The way I see it working is the apps would register themselves as the hovercard renderer for a particular type of object. You’d get a javascript call into your app code, which can do what it wants.

Frank Tarsillo: That makes sense, but it’s not the best use case. If an instrument is presented within a conversation, there’s something that recognizes the objects as associated with a specific datasource, which is different from an app, it would provide a hover-over with data, rather than an app.

Bruce Skingle: When I say app, I just mean something built on the extension API, which is Javascript running in the browser, served from your server.

Frank Tarsillo: We’re saying the same thing. Today we’re clicking on that app. But what I’m saying is there’s no choice, there’s a rendering of that data that’s already complete as a result of the hover.

Bruce Skingle: You’d have to provide an app that provides the hover rendering, using the same API.

Paul Teyssier: Now we have two questions to look into: should we look at how to do dynamic data first, via iframes, or create richer places where your renderer can manifest itself – in the message stream, hover cards, or entirely new elements?

Frank Tarsillo: Definitely from my perspective, the latter is preferable.

Action items

• Former user (Deleted) and Hershel Shah will produce a dataflow and mockups for the process of sourcing and displaying CDS reference data, and for linking it out to external applications.
  
  • Johan Sandersson will provide feedback once dataflow and mockups are available.
• Former user (Deleted) will put a draft EntityJSON object format for CDS reference data on the Confluence site.
• Former user (Deleted) will reformat existing XML object definitions in Confluence to EntityJSON and work with Former user (Deleted) on the CDS reference data format.
• Former user (Deleted) will prepare an end-to-end demo of new MessageML 2.0 renderer for the next meeting.
• Former user (Deleted) will work with Symphony LLC's Product Marketing team to create proposed "marketing" material describing the WG's activity in business-friendly terms.
• Aaron Williamson will invite Hershel Shah to sign up on Confluence and join the FOS mailing list and meetings.