...

Meeting notes

Johan Sandersson: Action items. Hershal, have you had a chance to have the currency object reviewed within IHSM?

Hershal Shah: Yes but I haven’t had time to document it. It’s in a notebook, so leave that one open and I’ll try to do it this week.

Johan Sandersson: Any other work on the CDS object?

Hershal Shah: We haven’t done much but would like to refocus on it. There’s no more work needed on the object itself, but there will be on the presentation of it. We’d like to couple it with pricing data. Hopefully we’ll see progress in the new year.

Johan Sandersson: Aaron, have you looked into whether there are any IP issues around Adaptive Cards?

Aaron Williamson: I have, and I don’t see any. Microsoft has licensed its own implementation under a permissive open source license, so to the extent it has any patents over that implementation, they should be covered by that license. They’ve also encouraged others to write their own implementations, so I don’t think there’s any risk they’ll assert patents against independent implementations (and if they did, it’s unlikely a court would enforce them).

Johan Sandersson: So what would the Foundation’s relationship to Adaptive Cards be? Should we be producing an implementation? Should we be encouraging the LLC to implement it? Bruce?

Bruce Skingle: I think this is obviously better in every way that what we’ve done, so my recommendation will be that we build it into the product, and I’ll put it on the platform team’s list.

Johan Sandersson: PS, how do you feel about this?

Peter Smulovics: Yes, that would much better that doing a custom renderer ourselves, because it will be available to everyone, it won’t be broken by updates, etc.

Johan Sandersson: Let’s recap the conversations about structured objects on Symphony. Can we clarify what each party would like to get out of some of the items we’re discussing here. What is Symphony LLC’s approach, what should be in PresentationML v. the actual object, how do we avoid duplication, does ordering within the JSON object matter, etc.? Peter and Bruce, you both had opinions here. Peter, can we start with your views on when ordering is important?

Peter Monks: To me, my first experience consuming EntityJS was poor, and I’m wondering what we can do to encourage vendors to produce JSON that’s interoperable and easy to consume downstream?

Johan Sandersson: On the mentions use case, can you give some details on what went wrong so we can understand better what we can do? Can we get something working soon where two firms are sharing data, standardize that first version, then revise as we see issues moving forward?

Peter Monks: My specific use case is a bot that exposes admin commands that should only be executable by known users in a list. In rooms & multiparty chats, the bot needs to be mentioned first in the chat for the command to be executed. And Dov gave another example where order of the data in EntityJSON would be critically important. Also, if a human is telling a bot to do something regarding a user, you also need to know that.

Aaron Williamson: What are you doing to discern order, Peter?

Peter Monks: I parse the JSON into an in-memory data structure, then pull the top-level keys out, then look at the type and version attributes for every key, and unless they match what my code is expecting…

[ Secretary couldn’t keep up. ]

Johan Sandersson: Instead of sending text with mentions where you…

[ Secretary couldn’t keep up. ]

Peter Monks: Yeah, but I’m not creating the messages in this case. But I’m also not interested in

Bruce Skingle: Two approaches. First, define an object that defines the subject, object, and relationship. Second, the person sending the message can express in prose what they’re trying to do, in which case you have to do the tokenization and text parsing that you’ve just described, there’s no way around it.

Peter Monks: True, but there are use cases where the mentions are the first thing processed. If I’m not mentioned, I do nothing. It would be helpful in taking the next step if the mentions were ordered. But this brings me back to my original question, which is whether the working group should try to express best practices about how EntityJSON should be structured.

Johan Sandersson: My take is that it’s maybe a little bit outside this group’s ambit & we should focus on the structure of objects, but we can follow up with a more formal question on the list. Bruce, do you have time in the next couple of weeks to define a draft security object?

Bruce Skingle: I should be able to. It’s a collection of IDs, that’s all, right?

Johan Sandersson: Well, I’d like to talk about that. Here are slides that Paul and I prepared to demonstrate an interesting way to use securities. Here, the user begins typing the name of a security, and the interface brings up a list of potential completions. When an object is created, it’s represented by a ticker symbol, but the object includes both the country ID and the name, as well as the list of IDs present in the object. Finally, we thought it would be a good idea to have a user choice within Symphony whether you want to display the ticker or the company name, though the functionality would be the same. The question, though, is even though this is duplicated information, should we have a two-letter country code and the name and ticker within the main security object, then the IDs in a subordinate structure.

Bruce Skingle: That’s not unreasonable.

Aaron Williamson: Should or can the long name be localized?

Johan Sandersson: I guess I’ve seen some kanji-translated names.

Bruce Skingle: Yes, localization would require multiple renderings of the names to be included in the object. There’s also the question of whether you should be concerned about, for example, a CUSIP licensee is sending licensed data to a non-licensee.

Johan Sandersson: Yes, that’s a good point, but I would think that it’s still their responsibility to decide whether it’s appropriate to include data. We’re just providing the ability to do it.

Bruce Skingle: So with the flag marker, if I received a DB ticker with a US flag next to it indicating it’s traded on a US exchange, that may be confusing.

Aaron Williamson: But that’s maybe just an argument for including less ambiguous disambiguation information in the object.

Johan Sandersson: Bruce, would you want to see this data at the top level, or in a sub-structure, e.g. “optional”?

Bruce Skingle: No, I’d just make it an attribute at the same level as ID. But I think we’d need to define the semantics of what that country code means in sufficient detail that it’s not confusing.

Attendees