...

Pre-work

• <list out pre-work here>

...

Meeting notes

• Recap of ESCo ratification vote:
  
  • Anthony: I was on the call where the vote took place, and can say that the ESCo generally want us to have success, and see the value of the group.  I expect they'll be very supportive of this group and help us succeed.
• Operating process / mechanics:
  • Anthony: we want to have fortnightly meetings - every 2nd Thursday at 9am US Pacific, starting in the new year.  Now that we're ratified, things we talk about are public on the wiki.  Discussions within the group should be within the (public) mailing list. Paul Teyssier is co-chair of the group (change from earlier versions of the charter).  Between us and Peter Monks we'll coordinate the group.  We want to have a clear & visible roster of membership & participation in the group - that's key in terms of having a well defined process for decision making & voting and who we can count on for contribution and decision making.  Paul, anything to add?
  • Paul: no that's a great summary.
• Work items:
  • Anthony: we want to identify the work items we should be creating & documenting.  The floor is open - what would people like to see in terms of work items?
  • Dov: in terms of the WG's mandate, there are a certain # of APIs that are available in Symphony right now.  It might make sense to present to the group what those are.  For example I have specific things that I'd like to understand more about the roadmap, and have missing capabilities I'd like to see.
    • Paul: in the platform roadmap (which includes APIs, but with the exception of the core UI application) there are 3 main families of APIs:
      1. Back end REST APIs.
      2. UI extensions & capabilities ("extension API")
      3. On-desktop process wrapper ("embedding API")
      • One of the concepts we're exploring with some members of this WG (in "pre-alpha") is an evolution of the REST API allowing them to be called from 3rd party systems that can be called "on behalf of" a given user.  It's a superset of the REST API and some of the extension API that can be used in a dedicated use case.  This is what we have today and to get to the next level down, every public API needs to be fully documented on developers.symphony.com - that's the authority of what we have and how it works, etc., and then in addition we publish YAML interface definitions which is the authority for the raw input/output parameters.  The functional definition of what it does is a but short in the YAML files, but is better documented in the developers.symphony.com docs.  Over time we'll have the YAML files point to the developers docs site for detailed docs.
    • Frank: I would call the Symphony APIs the "primitives".  The Java client is outside of that - it's leveraging those primitives.
    • Dov: In terms of how we would implement the primitive APIs, is this the group that would talk about that?  e.g. MessageML
      • Paul: two facets of MessageML - it's primarily a payload for message description and embedding of objects inside of messages.  To the extent that there's a problem statement that needs to be solved, we should talk about this in this group.  But for the sub-element of the objects inside the message payloads and create much bigger application use cases that can use Symphony as a transport, there's another working group (Financial Object Standardisation) that is primarily focused on what should be the standards for those objects, are those standards industry wide, bilateral, etc.  That work is happening in that working group - it's specifically focused on that one topic.
      • Dov: right now I've been looking at what other payloads can be pushed through Symphony, and what I've seen is that MessageML or plain text is it.  The notion of object embedding is part of FOS WG, but the idea of MessageML supporting arbitrary payloads seems to be missing.
      • Paul: I think the definition of how it will work imminently is by and large defined.  We can talk about it here or the other WG, or in a dedicated session with both groups.  But the target message format has been defined and has been discussed (to some extent) in the FOS WG.  We plan to ship this as a full set of capabilities early in the year.  If there are questions around if the format is extensible enough, it could happen in either WG.
      • Dov: the question is "what's beyond MessageML?  Why can't a put a title on links, etc.?"
      • Paul: the MessageML format does at least two things:
      1. 1. PresentationML - the raw description of messages inside Symphony clients - small number of tags supported (~7).  Lots of feedback from customers regarding limitations of this format.  Fixing this requires a much deeper re-engineering of Symphony - it's in progress and we have a roadmap, but it's a big change.  The goal is to support a much broader set of presentation- & security- safe HTML tags.  A roadmap of this is in place, but there's no really good date for this work.
            • Frank: is there a specification?
            • Paul: no, but there are draft specifications that take a subset of HTML tags (20 or 30).  No urgency to prepare a specification at this time.
            • Dov: so is a message PresentationML or MessageML?  The tag is <MessageML>.
            • Paul: right now the entire messages are sent as PresentationML.
            • Dov: we should fix that nomenclature
         2. EntityML: basically XML, so can represent virtually anything.  This is currently in alpha mode being worked on via the FOS WG.  To a large extent if you create objects that require rich rendering to the end user, the limitations of PresentationML become irrelevant due to custom renderers.
            • Dov: so the limitations of attachments might be mitigated by EntityML?
      • Anthony: I don't mean to interrupt but how should we capture this as a work item?
        • Dov: good point.  My thinking about why this is relevant is how API best help people interact most productively with the services the APIs are designed ot deal with.  If there's confusion around formats, names, capabilities then definitely should be something done in this group.  
        • Anthony: my understanding is that that work around consensus and definition of format or reusable definitions in terms of APIs is something this WG does.
        • Paul: how about we do this offline over email to figure out this scope?
        • Peter: let's use both WG's mailing lists for this
  • Leslie: we're most interested in "on behalf of".  What process should be used for this particular functionality?
    • Paul: this didn't surface in the original charter discussion.  But we are building those capabilities as we speak, and we're trying to have very involved conversations with a limited number of partners / customers.  It's an involved process so we can't work with 20-25 companies at the same time.  So to the extent that you have clearly defined use cases or clearly defined project, and just need more context / validation of fit, then that could be something we talk about as a group.
  • Frank: can't this group define the design patterns for APIs - whether they exist or not - this is an example of something that should exist.  Whether you take it into the LLC or not is irrelevant, but as a general comms platform this group expects this to exist.  How it's named, labeled etc. - nomenclature is important.  Is that something we'll be doing here?
    • Anthony: yes.  <quick recap of charter history for Leslie>
    • Frank: the purpose of the group is to define best practices for interfaces.  But we get to those definitions by identifying use cases and design patterns, then interfaces developed in the Foundation can follow those recommendations.  The LLC might also choose to follow them.
  • Paul: what is a good way to capture the work items we want to capture, and who are the owners?

    • Anthony: I see this as an exercise of shouting out work items and capturing them, and doing a readout to the group and larger list, then construct a path of work items from that list.  Looking for anyone on this call to propose potential work items.

  • Frank: use case definition - general design patterns from a use case perspective.  Things like "call routing", "on behalf of" - the basic primitives that are there - we should list those out.  Also things that are coming like audio / video.  As we start to look at the definition and usage of APIs we can start to link those up with design patterns and associated use cases.
  • Paul: seems to be a desire to formulate what would be the ideal best practice in terms of REST standards.  Is that still something we want to go after as a group?
    • Anthony: I'd support that, from a BNY perspective
    • Frank: I second that - absolutely
    • Dov: yep
  • Paul: another one I'd like to throw out: is there a guideline to be published for client builders - language bindings - in terms of what would be a good v1 definition of what such clients should do, both functional and non-functional?  In my head it's reverse engineering what Frank has done, and applying it to other languages.  Having this document thought through from this group would be very very useful.
    • Leslie: to me that document starts with terminology & a domain model
    • Paul: I agree - a domain model is a very interesting separate work item
    • Peter M: Matt Joyce (LLC engineer) has been developing a Python client, and I know this has been a topic of interest to him.  I'll take an action to engage him in this group.
    • Frank: we should be looking at use cases and then defining domain specifics and then cross-reference against what's been done to date
    • Anthony: I'm in favour of that being a work item we document and note down.  It also has a dependency on some of the definitions and terminology work we might do before that.  It's a bit of a catalyst for those basic design patterns sooner rather than later.
  • Will: part of the follow on is documentation around these standards?  With that documentation we have the ability to understand the applications and use cases.
    • Paul: the spirit here is that we are trying to define what artifacts we as a group believe will be most valuable, then we would create working teams to produce those artifacts.  It might not be the entire group owning the development of those artifacts, but sub-teams.
    • Anthony: this call will capture those, socialise back to the group, then we can figure out who's willing to work on what
  • Paul: I think we've mentioned around 4 very big & very interesting artifacts to date - I don't think we need to fish for more.
    • Anthony: and if there are other artifacts identified later on, we can also bring those back to the group
  • Paul: I think we also discussed there would be some ancillary work items we might want to tackle.  As everything we do will be public, we need to clarify for new joiners / other organisations what we do and how it fits together.  I don't know how urgent this is, but in terms of work items finding a way to explain what we do - maybe a wiki page - how it all fits together etc. would help the wider community.  As we figure out the work for the coming months this might be something we include.
    • Anthony: some content on wiki already
    • Peter M: access to Confluence and mailing lists might be problematic for some firms - I'll check that
• AOB: 
  • Anthony: next meeting January 12th at 9am US-Pacific
  • Paul: goal for next meeting: Anthony, Peter and I will huddle and capture the work items we identified today, and prior to the next call people will be ready to give their thoughts on these work items - which they'd be interested in participating in, etc.?  Any objections?
    • <none>
• Meeting adjourned

Action items

•  Former user (Deleted), Former user (Deleted), Peter Monks: distill above notes into list of work items, document them on the wiki, and share with the group via the mailing list
  
  •  All: review before next meeting and be ready to discuss which work items you'd like to participate in / contribute to
•  Peter Monks: engage Matt Joyce (Deactivated) in the group
•  Peter Monks: send out "access check" email regarding wiki and mailing list