Table of Contents

Date

23 Mar 2017

Attendees

Actions items from previous meetings

• Former user (Deleted) and Johan Sandersson will work together on visual examples to illustrate proposal
• 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

• Bruce Skingle: Is anyone else on the call besides those listed in WebEx?

• Paul Teyssier: Linus Petren from Symphony is with me.

• BS: The first thing on the agenda is for you to present the designs you’ve mocked up.

• PT: [Sharing screen] This is the artifact that the design team put together as we’re iterating over the design at Symphony. In the spirit of open collaboration, we wanted to show them to the working group as early as possible, to get your input.

• PT: [Slide 2] This slide illustrates the flexibility of PresentationML in rendering different kinds of messages. All of these are wireframes, not high-fidelity designs. Above is a simple message without any special styling. Below is an advanced message illustrating that message objects can be decorated in pretty advanced ways. Goal is to offer as much flexibility as needed to our customers.

• PT: [Slide 3] More complex content can be encapsulated in a card. Cards have a header and a body, which can be expanded by the user to reveal hidden content. Goal with expandable bodies is to support long-form content without interfering with the display.

• PT: [Slide 4] This slide shows all of the styles that go into decorating the more complex message shown on the previous slide.

• Frank Tarsillo: How will the objects represented in these example cards be classified?

• PT: This is just illustrating the presentation. You can put any kind of object you want in there. If you have an object that requires custom rendering, that would be specified in the EntityJSON. Cards are just a convenient means of presenting complex messages.

• BS: We currently display hover cards when you hover over cashtags and other links. Will that still happen here when you hover over a cashtag in a card?

• PT: Yes. But one of the questions we’re still exploring is how from design & tech standpoint to provide consistent behavior between links appearing in basic messages and those appearing in richer content rendered in an iFrame. If you specify a data-entity-id in the PresentationML and there is a renderer available for that object type, it will substitute the message with an iFrame, which allows the renderer to provide rich custom content to the end user. One problem we haven’t solved is users will expect certain behavior like hovering to work consistently within an iframe, but hover and iframes don’t work nicely together. Still have to define that soon.

• FT: If someone were to create an app outside of Symphony, to use an alternate UI, they’d need to support/interpret PresentationML, correct?

• BS: All messages are marked up in Presentation ML. As you can see in this card, there’s an IBM cashtag. Imagine there’s a CUSIP behind that. The PresentationML can still be rendered even your application doesn’t do anything with it. One possibility is that, if the user invokes the application for $IBM, the same screen real estate that the card occupies would be occupied by your application.

• FT: To be clear, if you’re writing an app that’s not Symphony and wants to support Symphony messages, it needs to render PresentationML.

• BS: Yes, but because PresentationML is a strict subset of HTML5, if you support HTML5, then all messages should render properly, assuming appropriate stylesheets are in place.

• Johan Sandersson: Let’s say you want to send a card with a cashtag to two different apps, one of which supports CUSIP and the other ISIN,what do you do?

• PT: We don’t envision this to be particularly complicated, but we don’t have a design for it right now. Let’s say we have this MessageML object in there. In the EntityJSON, it contains IDs for ISIN and CUSIP. In the UI, if nothing special is installed by the end user, it will render just the PresentationML and look like a Cashtag. When you take action on the UI element, the whole EntityJSON will be sent to the app that handles the cashtag capability.

• JS: That’s perfect, this is exactly what I was talking about. My only additional question is, is there any value in displaying the ISIN and CUSIP to the user?

• PT: One of the questions is, as an end user – if you look at the EntityJSON, the computer knows there’s more information than is being displayed (both ISIN and CUSIP), should that be displayed to the user? Or is that only of interest to the developer?

• BS: Why not just implement an app that can display everything that’s in the EntityJSON? Then the administrator could enable that or not. And Customers can implement their own version of that showing only what’s appropriate to their users.

• FT: There are definitely cases where the user will want to see that, but it all depends on the use case, so it should be available but it should be optional.

• JS: I think it’s a great idea. If Symphony developers a “hovercard” app that’s installed by default and is open source, other firms can adapt that to their use cases.

• PT: That’s useful, thanks everybody.

• JS: While we’re on that, is there a point where, when we’re identifying securities, we can get away from the dollar sign altogether? It’s a bit US-centric – if you’re trading currency and looking for the euro/pound rate, you still have to use the dollar sign. Can we just make the cashtag a link that just says “IBM”? We could make the functionality general so that every link gets a hovercard, which can be standard or can be advanced depending on the EntityJSON. You could use the same functionality to render contact information, etc.

• PT: Frank, do you have strong opinions?

• FT: I like the idea of getting rid of the dollar sign. But how would you get Symphony to interpret what text is a cashtag or link? How would the user manually put that in?

• BS: I would suggest that hashtags and cashtags are just two examples of structured objects. A cashtag is a financial security; hashtag is a keyword used to index content. I think the answer would be that the structure looks like it does on the screen here, minus the “$”. To introduce it, there’s a key sequence the user types, and a user preference defining what the introductory character is. Default could be “$” but can be defined by the user. If you want to use ISIN, you could type a dollar and then the ISIN and get the security for that ISIN.

• FT: So what would the keystrokes be?

• BS: In the default configuration, I’d type “$IBM”. If I’ve changed the introducer to F4 or Ctrl-Alt-G, then I’d use that, and that I’m going to type ISINs instead of tickers, then that set of strokes would provide the same behavior.

• FT: I like that idea. You know how users are, they want something really straightforward.

• JS: I think that’s really excellent, Bruce. Provides the same functionality but is presented in a different way and allows users to move over to advanced functionality without learning something new on day one.

• PT: From a UI perspective, we will be able to provide a wide variety of capabilities, but we can’t make it so wide that the users are confused. Two options are replacing cashtag as a primary citizen altogether and replace with more complex financial objects, and another is replacing the dollar sign as the default introducer. It takes a while for user habits to settle, so we should avoid changing it overnight.

• BS: But that’s supported by implementing the current behavior as the default and allowing the user to change it.

• PT: in my experience, less than 5% of users change settings.

• Linus Petren: Sounds like, technically, you’re leaving a lot of flexibility, so if it comes from an outside system, there are a lot of routes we can go internally. We can prompt users as they type, etc., but these problems don’t have to be solved immediately as long as we leave the flexibility to solve them in the future.

• FT: I agree with that. Symphony should start defining the entry point, as there will be more of these coming, so we should get ahead of those requests.

• PT: I want to make sure that as we build v1, which is very soon, it’s implemented very nicely.

• BS: If we replace cashtags and hashtags with a structured object, it will have an impact on signals, but hard to say what the implications are. On the opportunity side, gives us the possibility to have signals that look for an ISIN, so rather than saying “I’m interested in $IBM,” we could make signals much more specific. Would that be good/useful?

• Johan: Absolutely. I’d want to see the option to “add to signal” as in this slide, but then you can modify that signal to look for something more precise.

• PT: One of the biggest questions we need to resolve is, if we embrace the idea that the $ is just introducing “object entry mode,” then the impact on signals is significant, so we can’t leave this unsolved.

• Lawrence Miller: With regard to signals, we’d need to figure out how to generalize matching. Seems simple with a security, but if you’re trying to match a trade, there’s fuzziness as you try and handle more complex objects. Might need to do that in a more generic way that might involve tagging or hinting as you enter the objects.

• PT: Especially since everything’s encrypted.

• LM: Well, you’ll have to deal with that regardless. Certainly when it comes to parsing, I’ve always treated the $ as a trigger to enter object-entry mode. At BlackRock, we would be using BR’s own object description language. I’d tend to take the approach of delegating and allowing customers/integrators to decide how to parse objects, and let the user decide which parser they want to use. I view it as an implementation question for whoever’s building the parser. I wouldn’t want to try to put in a one-size-fits-all solution.

• PT: [Slide 8] One last thing, re: design. The installation experience. Let’s say this card is for one object, and there’s an app registered to render this object time. At display time, there’s a message on the object itself, saying go get this application. When you click it, the application inserts the rendered data. IT’s like what we do for articles. You get a snippet, click on full article, and if you have access to the application, it installs the app and renders the full article. So you’re providing an in-line installation experience, and a module application experience, providing richer data in the object.

• PT: That’s all I have. We have several questions to still work through re: cashtags and financial objects.

• FT: I think this is a good step forward. I think we’re all thinking, how do we input objects into the network. The auto-complete concept providing different options needs to be thought through. Everything else sounds good to me.

• Aaron Williamson: Would Symphony only show the option to fetch data via an app if it’s been enabled by the administrator?

• PT: At this stage, yes, only if the app is not blocked.

• JS: I’d love it if what you said about the more detailed data being available to the external app, if you could circulate that to a wider audience, because that’s very important.

• PT: From an execution standpoint, this is pretty deep in the guts of the code, so while we’d like to release that as we develop it, it might take a little longer. We’re going to reach a point where tech is mature enough that maybe a few months before the release, we’ll want to talk with customers about whether they have applications that would be improved by adding the financial objects capability, and we could pressure test the functionality with those apps. Please reach out to me if you are interested.

• FT: That’s one of the areas we’re exploring these years is making CDS data publicly available, and I think this hits the mark on that. The use case is right, but there’s a lot of engineering on your side. If I have a bunch of CDS data could you work with us on that integration?

• PT: Let’s talk about it offline.

• LM: I think the answer is just “yes.”

• JS: I think this is a good use case to test interactions between FactSet and Markit users.

• PT: We should follow up on the mailing list. We’ll reach out at the point where the members of the group pressure testing would be useful.

• Bruce: Thanks everyone, next meeting is in two weeks.

Action items

• 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.
     (UPDATE:  CDS Use Cases created,  Former user (Deleted) added to project.  Johan Sandersson, Former user (Deleted), Former user (Deleted) face to face meeting regarding POC work.   More work to do, but making good progress. 
  
  
• 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.