• See above

Action item from the 2016-09-20 meeting. From that conversation (summarised, and with emphasis added):

• Frank: Perhaps the focus on the container is too narrow?
  - - - - - - - - 8< - - - - - - - -
  Have you considered the implementation of a UI component?  Or is it focused on API interactions with the Symphony back end?  I see this WG as being about more than just the container
• James: in fact one of the problems was calling it the "Desktop Wrapper WG" from the get go, while not defining either term.  When I first started I couldn't tell if it was about the container or the APIs.
• Frank: my recommendation would be to revisit the charter of this group.  And change the "desktop" and "APIs" - I'm not saying we merge it with the API WG that Anthony is working on, but more the "extensions API".
• Lawrence: it's an interesting question around how you decompose this.  How do you integrate the UI elements and speak to the UI elements.  They're all rendered in HTML, so when you talk about the user visible constructs, are they components of the API or are they aspects of which HTML widget libraries do you use in the HTML front end code, whether it's API related or not?  Are you talking about an API or an HTML coding standard?  I don't mean to complicate it, but I think it's a really good idea to try to figure out where these things should live.
• James: it's an ontology question, and would also help with Anthony's WG.  If we're going to have WGs around Symphony, perhaps ESCo needs to define an ontology of WGs, both of the current ones and future ones.

Proposed objective for this agenda item (comments welcome!): decide whether the ESCo should define a WG ontology, and if so, when and how.

From ESCo mailing list:

"Is there any follow-up discussion we should have to address the -1 concerns?"

From the previous ESCo meeting:

"Laurence: I think we should have James participate, but the comment I have is that we've approved a contribution where the contributing party voted against it. That's odd. And we should move it to the next agenda so we can discuss with James. I think the other ESCo members agree that it's odd.
Frank: Agreed. And I had a question about how far the CONTRIB was going to go - API access etc. - that we need James for. It was odd that James voted down his own contribution."