...

Meeting notes

Johan Sandersson: Let’s jump straight into Peter’s presentation about Adaptive Cards and SSML. I think on the cards side it’s good to have Bruce on board from the LLC to compare with the existing card functionality.

Peter Smulovics: So the two topics I want to talk about is SSML and Adaptive Cards. I’m approaching these from the perspective from Section 508, which is about supporting accessibility for disabled users. SSML allows you to markup text to support text-to-speech tools and machine-learning tools like Alexa. When you render speech you get XML containing the interpretation. And what I did at the hackathon was to create an SSML interpreter and convert it as a renderer to audible voice. So you can use an MPL module like Alexa Speech on the server side and emit listenable audio from Symphony. So my suggestion is that this group vote to approve SSML as a basic building block (like Integer and String) to provide speech as part of a business object.

The other thing I’d like to speak about is defining cards. I’ll show some examples of Adaptive Cards. The idea is that there can be many renderers for the same JSON card, which is a nonvisual representation. And it supports SSML, so when you click “Speak this card,” it will render it audible. So using Adaptive Cards as a similar basic building block to represent the feedback coming from a bot, would allow us to easily augment that text with something like a screen reader. You can do really complex things with adaptive cards. Here’s another thing I did as part of the hackathon, which was to create a rudimentary renderer to render an adaptive card as PresentationML. So here the structured object contains the whole card and from that I generate the view you see here.

Bruce Skingle: So what does the PresentationML look like?

Peter Smulovics: It’s JSON just specifying what you see on the screen, rather than the presentation of it. And it’s a standard so there are already a lot of different renderers for it, some from Microsoft and some without.

Bruce Skingle: So you’ve just wrapped the card in an EntityJSON object?

Peter Smulovics: Yes. I just put the JSON inside the entity.

Bruce Skingle: My concern with SSML is that we’ve backed away from XML because we ended up in all sorts of escaping nightmares.

Peter Smulovics: Yes, but it’s just the XML representation of the entity description. It would only contain the information necessary for someone who needed the speech rendering. For example, from this flight card, the only part that’s rendered is this one sentence.

Bruce Skingle: So you don’t envision people sending messages as SSML, but as cards that would get rendered into SSML.

Peter Smulovics: In some cases, yes, but usually you’d have only very simple SSML embedded in a JSON string.

Johan Sandersson: Do you see that as being available only on certain objects, or do you think the entire chat session should be speakable?

Peter Smulovics: I think that most of the session would already be easily renderable as speech. What’s needed is a way to render custom-rendered structured objects as intelligible speech. I actually have friends at MS who are sight-disabled, and they struggle with custom-rendered objects in software like Symphony.

Bruce Skingle: I think there are a couple of questions. First, whether PresentationML should allow SSML as markup. Second, whether to define a structured object type that is an Adaptive Card. And that seems like a slam dunk to me. And then maybe if it really is a standard – this came out of Microsoft?

Peter Smulovics: They’re the biggest implementer but there are many others.

Bruce Skingle: Is a standards body managing it or does Microsoft own it?

Peter Smulovics: I’m not sure, that’s an interesting question.

Bruce Skingle: So if we extended PresentationML to allow SSML, how many tags are part of the standard? That goes to whether to expand PresentationML to include them, or whether to support it another way.

Peter Smulovics: It’s a maximum of 20.

Bruce Skingle: I’ll take it as an action to see what the viability is of building Adaptive Cards into the base product as a custom renderer. What do others think?

Johan Sandersson: I like both ideas. If we could define, or say we’re going to support an object that supports the Adaptive Cards standard, and the LLC builds a renderer, I think that’s a good piece of work. And I think building SSML into PresentationML is great, I think that’s the right place for it to live.

Peter Smulovics: I just counted, and there are 11 tags total in the SSML specification.

Bruce Skingle: And I assume that for the purpose of rendering the text on the screen, you just strip all the cards out. Ok, so I’ll take this back to the product team and report back to the group.

Johan Sandersson: Could you add these to the wiki page?

Peter Smulovics: I can’t, because in MS we can’t edit Confluence.

Johan Sandersson: Ok, just send me the two links and I’ll put them up.

Peter Smulovics: Yes, I’ve just put them in the chat:

https://www.w3.org/TR/speech-synthesis11/

https://developer.amazon.com/docs/custom-skills/speech-synthesis-markup-language-ssml-reference.html

https://www.npmjs.com/package/alexa-speech

http://adaptivecards.io/

http://adaptivecards.io/explorer/

http://adaptivecards.io/visualizer/index.html?hostApp=GroupMe%20(Bot%20Framework)

http://adaptivecards.io/samples/FlightItinerary.html

Johan Sandersson: Peter, how are these handled on mobile devices?

Peter Smulovics: They have mobile renderers as well, and even renderers to send as a text message as fallback, as a static image. And they have a native iOS renderer, for example, that you can use in your application. And it seems very easy to use.

Johan Sandersson: I saw some examples for Facebook and Telegram, do their mobile applications support this?

Peter Smulovics: I would guess that they do.

Johan Sandersson: Bruce, would it be ok to bring in the mobile team on this as well?

Bruce Skingle: Yes, if we’re going to support it in the base product, we’ll do so across products.

Johan Sandersson: Great, well let’s move on for now. I want to talk a bit about the Security object, which is obviously one of the main reasons we got together to begin with. Bruce put this draft together for a Security container object. I think this is a good candidate for our next standard. I think we should identify a set of supported identifier types. For example, should we support OpenFIGI, or do we know enough about it?

Bruce Skingle: I don’t see any reason to omit any standard ID types that we know about.

Johan Sandersson: But is there a clear understanding of what the difference between a RIC code and a PermID?

Bruce Skingle: Well, presumably we could figure that out from the website there.

Johan Sandersson: Is there anything to stop an organization from sending a security without an identifier?

Bruce Skingle: No, there’s intentionally no barrier to that.

Johan Sandersson: Right, but our preferred way of working would be for anyone sending another type of security that we don’t already have a type for it. It would be good to have agreement within the group that our firms will use these types if they’re defined, but we may not be able to do that today.

Aaron Williamson: How should namespaces be defined for proprietary identifiers?

Bruce Skingle: I think that we can put whatever we think is appropriate in the symphonyoss namespace. I think it’s better to do that than to encourage others to invent one in their own namespace. So if JP Morgan has an internal identifier, that should absolutely be in their namespace, but if it’s an external identifier and they’re just the first to use it in structured objects, it should be in the symphonyoss namespace.

Johan Sandersson: I think for a proprietary identifier that originates from a Foundation member, it’s appropriate for that to be defined in the member’s namespace.

Bruce Skingle: I agree, but for proprietary identifiers of non-members like Bloomberg, where we don’t know what their internal namespace for it is, we should just put it in org.symphonyoss.

Peter Smulovics: Next, I wanted to talk about FactSet’s RFQ work using our own version of structured objects. I wanted to put those out here to talk about making them standards objects. We did a version where a trader can send an RFQ and a broker can see it in a structured format and can respond using a custom-rendered object within Symphony. The response is put into a Symphony chat, then picked up by our bot and sent back to our backend systems. So what I put together was the request portion of an RFQ for a bond.

Bruce Skingle: So you’ve got “request” in there type. An RFQ is the request, the response is just a quote, right?

Johan Sandersson: Well, the response could just be a “deny.”

Bruce Skingle: Right. I don’t think the length of an identifier is a big problem. Users aren’t typing these.

Johan Sandersson: So the object has the required type and version, then I have an ID element. Here I’ve defined one using our portware ID.

Bruce Skingle: I think this structure is not syntactically valid – you need to take the “portware” part and those braces out.

Johan Sandersson: So next we have “side” to identify whether this is coming from the buy or sell side.

Bruce Skingle: We talked previously about using JSON schema for standardizing the description of objects. And if you did, this would be an enumeration: “Buy, Sell.”

Peter Smulovics: And here is a structure for including ratings from various institutions. I think in the future we’d want these rating types standardized.

Bruce Skingle: If I’m asking for a quote, why would I include ratings?

Time is running out, but I spoke to someone to someone who said, if you’re going to support an RFQ object, why wouldn’t you just use the standard from FIX? And also, if we’re going to have a meaningful conversation, shouldn’t we have people participating from both sides of the transaction? Do we have anyone here that is interested in answering RFQs?

Johan Sandersson: I can see if I can get our team who came up with this to get our counterparties to participate.

Bruce Skingle: I think it would be very helpful to bring those people in.

Attendees