Table of Contents

Date

18 May 2017

Actions items from previous meetings

• Former user (Deleted) develop a proof-of-concept bot to recognize CDS entity references and respond with in-line data about the security.
  • All: contact Former user (Deleted) if you're interested in working on a custom renderer for the CDS data returned by the bot
• 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 work with Symphony LLC's Product Marketing team to create proposed "marketing" material describing the WG's activity in business-friendly terms.

Agenda

Action items

N/A

Meeting notes

BS: I’ve translated a couple of the MessageML XML objects to the EntityJSON format, including org.symphonyoss.fin.security and com.symphony.integration.jira.event.updated. [Bruce walked through the objects.] I’ll mark that action item as done. Frank, do you have an update on the CDS implementation?

FT: We’re preparing the content on our side. We’re waiting for MessageML v.2 availability within our test pod so we can develop to it. I do have one question about the MessageML v2 parser, I wasn’t sure if that was going to be open source immediately.

BS: I thought we’d contributed that. Aaron?

AW: Yes, the CONTRIB is in, hasn’t ESCo approved it?

FT: We have, I just wasn’t sure of the status.

PM: It’s very close, just waiting for the administrative user to have access to the repository.

BS: Is it possible we’ll be able to work across customer boundaries on the CDS data? Is anyone else engaged besides IHS Markit and FactSet?

FT: Not that I’m aware of.

BS: Is anyone else on the call interested or willing to engage in that? I think if we could collaborate across companies that would really help move things forward.

AW: Are there other objects that would be of broader interest?

BS: That’s sort of been what we’ve been trying to do for some time.

JS: This is Jeff from Ipreo, we’re new to this process, but has the group considered modeling company entities, like companies, issuers, that sort of thing?

BS: We haven’t talked about that in the past.

LM: It’s something that would be contemplated by the general structure we’ve created.

FT: Is this LEI data we’re talking about?

JS: Yes, company, investors, the hierarchy. We’re coming from the big dough world, so that’s where we have the most focus.

BS: If there’s some subdomain you’re interested in producing a specification for, please go ahead into the wiki and propose something you have domain expertise on. We did have a group discussing these when they were first created, and what the appropriate representation of time is, that sort of thing. I’d be very happy to work with you to get something together. The bottom line is, are there people who want to send and receive this kind of message. I don’t know if this is clear to everyone, but part of what we’re doing in the current release is changing the markup for hashtags and cashtags to make them first-class entities. There’s currently no way to enter a complex cashtag w/ISIN and CUSIP in the UI, but you can via the API. We’re working to enable that in the UI. And maybe that will be what increases interest in doing more complex things with the objects. Anything else anyone would like to raise?

JS: That was a question I was going to ask to Paul, which is whether progress had been made on StructuredObjects 1.1?

BS: I’m pretty sure we’re not working on development on that yet because we’re still working on getting 46 released, but I’ll ask him to fill you in.

There’s this other question about the ISO 20022 standard and whether we ought to work with that in some way. And our charter is about messages sent between humans, and we were specifically excluding reimplementations of FIX, etc. So I’d say it’s probably out of scope, but we want to be more than a chat platform, but I don’t see why we couldn’t handle all sorts of payloads.

AW: To the extent that ISO 20022 has already defined some of the objects that this group is looking at, does it make sense to look at those rather than redo that work.

BS: It may well be that ISO 20022 has definitions or structures that would be useful. Frankly, if any two customers said we want to exchange messages and they have to be in this format, we’d say we’ll support that. But so far nobody’s said anything like that. So I think switching formats is pointless unless anyone is planning to use the objects.

Initially, we did define an XML format for MessageML, and we’ve switched to this combination of PresentationML and EntityJSON on the basis of experience. And although we haven’t convinced anyone else to use this, in building our own apps and integrations, we’ve had feedback that the XML is really hard to use. And my gut feel is that the difference between JSON and XML is similar to the difference between ISO 20022 and TCP/IP. The one may be more rigorous, but it’s hard to work with, so in the end people are probably just converting back and forth to JSON. And while I might not like JSON’s lack of rigor, it probably makes it easier to get things done.

PD: It looks like ISO 20022 and FIX overlap considerably, and looks like MessageML might create further overlap. Are there plans to build a conversion layer?

BS: If that’s something our community wants, it’s something we’ll build. But FIX is a system-to-system format, whereas we’re looking at objects being sent in chat messages, which will be displayed to a user in some interesting way. If I were being asked to replace a FIX gateway in a financial institution, Symphony would not be my first choice.

LM: I think we’re going way down a theoretical path of assumptions. To the immediate question, certainly OMS is connecting into Symphony as a messaging tool is something we’re talking about. But as Bruce says, these are not likely to be machine-to-machine, but you might send a trade out of an OMS to a user on Symphony and that fits well into our model. And then the question is what format do you use, and I think we want to use established formats where they’re available. And I think that’s going to be determined by whoever first starts sending messages over the network.

JS: I support that, that there’s nothing stopping us putting FIX or ISO into the payload of the message, but for practical purposes, trying to adhere to them with everything in MessageML would be more effort than it was worth, given that we’re operating on a messaging platform and not a clearing system.

LM: I think that whatever the most natural and straightforward format to represent the thing is what we’ll use.

JS: Do we need an entity to specify the format it’s using and requiring the message to adhere to that?

BS: One difficulty with XML is the degree of escaping necessary to send a complex message. To shoehorn in another format in an existing Symphony message would not be very sensible. So without an actual use case, I think we’re just guessing in the dark. If someone came and said we have an OMS that omits FIX messages and we want to send it to someone, I’d say write a bot that takes a FIX message and creates a MessageML object.

If you want to say, look at this security on this exchange between these dates, that’s a variety of objects

JS: I think that’s a fair point and as you say, it’s all about use cases or user-driven demand. I sometimes hear people speak of doing the thing you’re saying is not ideal, which is using Symphony as a platform for transmitting messages system-to-system.

BS: What I have an issue with is doing a lot of work to define a bunch of theoretically useful objects in a particular format before anyone is actually using them.

JS: I think that this all becomes much clearer when we get StructuredObjects 1.1, how you can work with these various things in different contexts and use cases. At this stage it’s a bit theoretical.

BS: I think you’re right that it’s harder to understand without visual examples and I hope you’re right that people will be engaged once we do. Any other business?

Attendees