Table of Contents

Date

Dec 8, 2016

Attendees

Actions items from previous meetings

Agenda

Meeting notes

• Bruce: no prepared agenda for today, and small attendance.  It feels like we've gone as far with this working group as we can, for the time being.  Once we have different enterprises engaging in interactions using financial objects, then it might make sense to pick it back up.  If the product contained more complete product functionality to support this, we might have higher engagement, but product management are not hearing about this from customers.  I was going to cancel the next meeting anyway, and given today's attendance it's unlikely we'll get better attendance the following meeting (January).  So I suggest I'll send an email to the group saying "unless anyone has things they'd like to discuss, then I think we should stop having regular meetings but keep the group in existence"

• Johan: one thing I've been pondering - whether there's interest from anyone to look at some sort of "financial objects lite", which would not be the complete renderer as today, but actually just being able to embed entities for just objects so that you could send along a piece of text that contains a rich object, just for an identifier say, but not necessarily use a custom renderer for the entire message.  So Symphony would have to natively render an entity of type "security" or whatever.  Then we could implement bots that send objects that contain all the information, and that is presented to the user as one item without requiring an installed renderer.  It's kind of "cashtag 2.0".

• Bruce: that was kind of the original intent.  So I guess from an engineering standpoint we've kind of done what we need to do to define that solution.  The barrier is that the internal representation of messages is a hideous markdown + JSON structure.  It simply can't represent anything other than what it currently does.  For example there's an email conversation going on about MessageML being broken - e.g. you can't put text in an <a> tag.  I replied and said it has nothing to do with MessageML - it has everything to do with storage.  So in order to move this forward we'd have to change the way messages are stored, and the reason it's proven difficult to make that change is that it's wide reaching - shallow, but broad - all of the clients need to change, and content export as well.  We know what we need to do to make that happen, but we can't get the product management to put it it at the top of the list - there's always some new thing that gets priority.  It frankly comes down to: if enough customers ask for it, it will get done.  We've done a hack (which is MessageML v2, now in production), in order to support the recent integrations, but it wasn't enough to justify the complete fix.

• Johan: I will continue trying to drum up other clients to come and give the same message.  We have some joint customers who have expressed issues with the current limitations.

• Peter: I also wanted to mention SavaNet.  They are considering Foundation membership, since they are keen to join this working group and share some of their experiences around modeling financial objects in the XBRL standard (which they've been contributing to for over a decade).  Perhaps there's a possibility to switch gears and focus on defining financial object models for a while?

• Bruce: yes we have some models on the wiki already.

• Peter: yes and if there's interest from the firms who are participating in this WG in the kinds of objects we come up with, it might highlight the value of the fully-functional MessageML vNext you've mentioned and the firms might be incentivised to clearly state their need for this to product management?

• Bruce: that's plausible.  Would SaveNet join by the January meeting?

• Peter: we're working to have them become a member before year-end, but that's not a guarantee

• Bruce: ok then let's keep the first meeting in January and see what happens

• AOB:

  • Bruce: Next meeting is the Christmas week, so it will be canceled

Action items