The Music Notation Community Group develops and maintains format and language specifications for notated music used by web, desktop, and mobile applications. The group aims to serve a broad range of users engaging in music-related activities involving notation, and will document these use cases.
The initial task of the Community Group is to maintain and update the MusicXML and SMuFL (Standard Music Font Layout) specifications. The goals are to evolve the specifications to handle new use cases and technologies, including greater use of music notation on the web, while maximizing the existing investment in implementations of the existing MusicXML 3.0 and SMuFL specifications.
Note: Community Groups are proposed and run by the community. Although W3C hosts these conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
Adrian has updated the mnxconverter project to handle all of the repeat barlines and repeat endings examples given in the MNX-Common by Example page.
Up next, Adrian will update the MNX-Common specification to cover the repeat barlines, endings and jumps. Thereafter, Adrian will update the mnxconverter project to handle repeat jumps.
Once these tasks are complete, the next priority will be to add to the MNX-Common by Example page examples for part grouping, based on the community discussion that has been going on in the new issue #185. The plan is to base the new examples on the proposal for the staff-group element in this comment from James Ingram.
Next meeting
The next co-chair meeting is planned for Tuesday 21 July 2020.
Pull request #318 closing issue #291 has now been merged, and Michael is next planning to work on a pull request addressing issue #254.
MNX-Common
After discussion at the last co-chairs meeting, Adrian has continued to work on the examples for repeat endings and structures, and pull request #186 has been updated taking that feedback and some community feedback into account. The co-chairs discussed using a type value of discontinue (instead of stop) for the final ending in a repeat structure. Having made that change, the co-chairs agreed that this pull request is ready to be merged.
Two further pull requests will follow, one to add repeat endings to the MNX converter project, and one to update the MNX-Common specification in this area.
The co-chairs discussed issue #185. The co-chairs discussed closing some old issues. Issue #185 will remain open but should from now on be more focused on how parts should be grouped; the useful discussion on the other aspects, such as system and staff formatting (which is covered by issue #57), differences between scores and instrumental parts (covered by issue #38), and how to handle collections of related musical documents within a single MNX-Common document (already described in the specification, but which can be reviewed in in the new issue #188). The co-chairs encourage the community members who have created proposals in these areas to move the current state of each of those proposals to the relevant new issue.
The co-chairs see promise in the proposal worked on by the community in issue #185 described as the staffGroup element, and will work on including this in the MNX-Common by Example and the specification as the next priority, once the current work on repeat structures is complete.
The co-chairs also agreed that issue #138 should now be closed.
Next meeting
The next co-chair meeting is scheduled for Tuesday 7 July 2020.
Adrian has been working on a pull request (#186) for new examples added to the MNX-Common by Example page showing a proposal for how repeat barlines, jumps and markers could be represented. There are five examples added: three examples of repeats involving repeat barlines, and two involving jumps.
The co-chairs discussed the proposal and agreed that in order to accommodate repeat endings that are longer than a single bar, we need to separate the start and end of these structures so that they can be declared in different bars if need be. The co-chairs also discussed whether or not it should be necessary to encode the different types of D.S. jump (such as D.S., D.S. al Fine, D.S. al Coda) separately, and came down on the side of specifying them separately; this is not perhaps strictly necessary but makes consistency-checking of the overall repeat structure easier.
The co-chairs also discussed the issue of how the presentation of repeat jumps such as D.S. al Fine should be handled, since these often mix musical symbols with plain textual content. The text aspect of the elements will be removed for now, pending a wider discussion about how best to encode these kinds of markings in future, since they tend to occupy a grey area between semantic and presentational data.
The co-chairs briefly discussed the recent work being done by community members on the issue of how parts should be grouped in MNX-Common in issue #185, and will both review the discussion, comment on the issue, and potentially discuss in more detail in the next co-chairs’ meeting.
Next meeting
The next co-chairs meeting will take place on Tuesday 23 June 2020.
MIchael has completed the first pull request (#315) for MusicXML 4.0, updating version. Issue #291 is currently in progress. Michael’s plan is to start with some of the Documentation issues before progressing to the more substantive issues.
The co-chairs also reiterate that anybody who wishes to contibute to the project, whether it is in the form of participating in discussions on issues but more critically when working on pull requests, must join the Community Group and agree to the terms of the W3C Contributor License Agreement. If you do not join the group and agree to the CLA, we cannot accept your contributions.
MNX-Common
Adrian has been working on a proposal for repeat barlines and markers to address issue #174. The co-chairs had a discussion about the approach we might take in MNX-Common to encode repeat barlines, repeat endings, and coda/segno markings. Adrian will proceed along the lines of taking the attributes that are part of the barline and sound elements in MusicXML and consider how they might best fit into the existing structure of MNX-Common, perhaps in a new jump element. Adrian will work on the proposal in the coming weeks and will have something to share with the community soon.
Next meeting
The next co-chair meeting will take place on Tuesday 9 June 2020.
Following the discussion in the recent Community Group meeting, Michael created issue #314 to canvass the community over the issue of whether or not the version number for the next version of MusicXML should be 3.2 or 4.0. There is a narrow majority in support of MusicXML 4.0 so this is what we are going to do. Michael will create an initial pull request to change the version number, copyright date, and switch the license back from the Final Specification Agreement (FSA) to the Contributor License Agreement (CLA), which is the appropriate license to use for the development process.
The co-chairs also discussed issue #313, which can be closed. Michael will review the outstanding issues in the MusicXML repository for those that will be deferred to MNX, ensure that a corresponding MNX issue exists, and then close those issues.
Adrian will next add some examples for transposing instruments to the MNX-Common by Example.
Adrian will add links to the new mnxconverter project to the various pages on GitHub that should have them, and Michael will contact our W3C representative to add a link to the mnxconverter repository to the CG home page.
Next up will be a proposal for how to encode repeats in their generality, including repeat barlines, repeat endings, and repeat jumps.
On the subject of how MNX-Common and MNX-Generic should be named, following the discussion at the Community Group meeting a couple of weeks ago, Adrian will start a new issue to capture any further feedback from the community.
Next meeting
The next co-chair meeting will be on Tuesday 26 May 2020.
The W3C Music Notation Community Group met online in a Zoom meeting on Thursday, 30 April 2020 between 2:00 pm and 4:00 pm UTC.
CG co-chairs Michael Good, Daniel Spreadbury, and Adrian Holovaty chaired the meeting, with 37 members of the CG and interested guests attending. The presentations from the meeting are posted at:
We recorded the meeting on Zoom and have posted it online at YouTube. Zoom provides an automatic transcription feature, so there is also a complete transcript available via closed captioning. The video starting times for each part of the meeting are included in the headings below.
Much of the group discussion happened in the Zoom chat window. We have incorporated highlights into these minutes, and you can also see the full chat log.
Attendees
Here are the meeting attendees in alphabetical order by organization:
Arshia Cont, Antescofo
Dominique Vandenneucker, Arpege / MakeMusic
Haipeng Hu, BrailleOrch / Open Braille Music
Dominik Hörnel, capella-software
Markus Hübenthal, capella-software
Christof Schardt, Columbus Soft
James Sutton, Dolphin Computing
James Ingram, self
Oleksil Sapov, Internationale Stiftung Mozarteum
Bonnie Janofsky, self
Jim DeLaHunt, Keyboard Philharmonic
Michael Good, MakeMusic
Jason Wick, MakeMusic
Michael Cuthbert, MIT
Peter Jonas, MuseScore / OpenScore
Martin Keary, MuseScore
Daniel Ray, MuseScore
Benjamin Bohl, The Music Encoding Initiative
Christina Noel, Musicnotes
Matan Daskal, Newzik
Marin Fauvel, Newzik
Kenzi Noike, self
Reinhold Hoffmann, Notation Software
Philip Rothman, NYC Music Services / Scoring Notes
James Opstad, self
Eric Carraway, percuss.io
Laurent Pugin, RISM
Jeremy Sawruk, self
Matt Briggs, Semitone (Komp)
Ben Spratling, Sing Accord
Jeff Kellem, Slanted Hall
Adrian Holovaty, Soundslice
Daniel Spreadbury, Steinberg
George Litterst, TimeWarp Technologies
Cyril Coutelier, Tutteo (Flat.io)
Roger Firman, UKAAF / MSA
Fabrizio Ferrari, Virtual Sheet Music
Introduction (0:22)
Michael welcomed everybody to the meeting. He outlined the rules of engagement for holding a meeting over Zoom, encouraging the participants to use the “raise hand” feature in the Participants list.
Michael introduced the W3C Music Notation Community Group and encouraged those in attendance to join the CG if they would like to contribute.
MusicXML 3.2 (5:17)
Michael introduced the goals for MusicXML 3.2, in particular to improve the support for parts and scores. The intent is to continue to work on both MusicXML and MNX in parallel, but to defer any use cases that cannot be solved without making major changes to MusicXML to the MNX effort.
Michael outlined the six main themes for the MusicXML 3.2 release, which can be seen in the V3.2 milestone in the GitHub repository, with a target completion date of the first quarter of 2021.
Improved Parts Support (9:04)
There are currently 8 issues in scope with the Parts label in the GitHub repository.
At the time of MusicXML’s inception 20 years ago there was no support in notation software for having the score and parts linked together or stored in the same file, and it was designed to model the experience of working with paper scores. Today things are very different, and in particular there is a specific need for Finale and SmartMusic to handle parts in a more sophisticated way. The approach that has been followed to date is to embed separate MusicXML files for each part in the MusicXML file, with a linking mechanism to correlate each MusicXML part in the score MusicXML file to each individual MusicXML part.
A goal is also to improve the interchange of part information even if you are exchanging only a single uncompressed MusicXML file rather than a compressed .mxl archive containing multiple MusicXML documents. MusicXML currently behaves poorly with concert pitch score documents, so one way in which this restriction can be eased is by providing information about the transposition of each part to be used when the score is viewed in transposed pitch (issue 279).
Michael had pointed out that one constraint on the design concerns trying to avoid particular patents. Jim DeLaHunt asked if these IP issues were enumerated anywhere, and Michael pointed out that the main issue concerns a patent held by Avid in the area of linked parts.
Machine Listening (16:15)
Machine listening applications include Metronaut and SmartMusic. These kinds of applications have different requirements and may need additional information that is not encoded notationally in the score. MusicXML provides the sound and play elements to provide supplemental information things that are not represented directly in the score, and the proposal is to add a new listen element, which would have a counterpart in a new player element, which would allow individual instruments to be grouped by player, handling divisi, and so on.
Michael outlined the different requirements that may exist for synchronization, including situations where the computer needs to wait for the performer, and those where the performer is expected to keep up with the computer.
Bob Hamblok had raised concerns about the amount of additional data that might be required to represent this new data intended for machine listening applications, but Michael sought to point out that the amount of data that will need to be encoded will not be significant.
Arshia Cont spoke to reassure other members that the additional data for synchronization etc. can be useful to applications that are interested in playback, as they can be used to improve humanisation of playback etc. Arshia expressed his strong support for this initiative in MusicXML 3.2.
Michael Cuthbert pointed out that “the sum total of all MusicXML ever generated might be about the same about of data as this 40-part video chat today is going to create, so from my perspective, let’s keep the data in our encoding!”
Tools (26:07)
Antescofo suggested that introducing an XML catalog would be helpful. If you’re validating a MusicXML file, the validation against the schema or DTD will go out to the web location, but XML catalogs make validation against a local copy of the schema or DTD much easier.
We cannot add an XML namespace to MusicXML without breaking compatibility with older MusicXML files, so the proposal is instead to adopt a standard namespace so that MusicXML can be combined with other XML vocabularies, when embedding MusicXML into other documents.
Michael spoke about some of the issues that exist with using code generation to create classes based on MusicXML, which have largely now got solutions. The goal is to document those solutions, and to ensure that any new features are not implemented in such a way as to be likely to introduce problems with code generation tools.
Another idea is to introduce XSLT stylesheets to automatically generate ID attributes for items in MusicXML.
It is also the intention to update the DTD and schema locations to reflect their current secure HTTPS locations.
Jim asked whether or not this tooling support might include additional features for producing a concise set of differences between two different scores, e.g. to facilitate the exchange of small differences like annotations. Michael pointed out that this might be more an application-level problem and not something that we would necessarily tackle as part of the format itself. Michael Cuthbert pointed out that this kind of diffing is very difficult – he has had two masters students working on the problem without completely solving it.
Gaps in Appearance (34:33)
Michael outlined a number of presentational items that cannot currently be described adequately in MusicXML, including some enclosure types, the appearance of measure numbering for multi-bar rests, and so on.
Percussion grids (staves with wider than normal spacing) cannot be easily represented in MusicXML, so Michael proposes some changes to help improve this.
Michael also proposes that it might be time to tackle some long-standing alignment issues, including the vertical positioning of rests and the horizontal extents of barlines.
Gaps in Playback (41:11)
Adding support for swing in the form of a ratio etc. rather than relying on the duration and type values for note elements work to define the difference between the printed and played values. Daniel Ray proposes that perhaps using a set of swing descriptions, rather than numerically.
To allow better support for doublings, it’s important to be able to change instrument for virtual instruments in the same way as changing MIDI instruments.
The sounds.xml file hasn’t been updated since MusicXML 3.0, despite the intention of defining it as a separate file in order to allow it to be updated on a faster cycle than MusicXML itself. But the time has come to add at least one more tin whistle sound, and potentially further sounds if needed. Michael invites proposals for any other sounds that are not currently covered.
Benjamin Bohl says: “In terms of performance parameters I’d like to point you to the “Music Performance Markup“ model for describing performance parameters: https://github.com/axelberndt/MPM”
Documentation (47:07)
Improving the MusicXML documentation is a never-ending task. Michael welcomes a volunteer to help improve the design of Roman numerals for harmonic analysis, and Michael Cuthbert stepped forward to take this on.
Michael also says that moving the existing documentation for MusicXML 3.0 to the W3C site is a goal, but it’s challenging because it was authored in a moribund version of a proprietary tool.
Postponed to MNX (50:37)
Issues that will require greatly expanding the semantics of MusicXML for text and lines are going to be deferred to MNX.
Next Steps (52:23)
Michael asked the group whether this seems like a reasonable scope for the new version. Michael is also inclined to give MusicXML 3.2 the version 4.0.
Benjamin Bohl suggested that we might follow semantic versioning, but Michael is not keen on this as he doesn’t feel this is especially appropriate for slow-moving formats like MusicXML.
Support for both 3.2 and 4.0 appeared to be roughly even among the attendees. Michael proposed that we would conclude this topic after the meeting, perhaps with a formal poll among CG members in due course. We did a “show of hands” and 4.0 came out ahead roughly 2:1.
Community Group Membership (57:17)
Michael once again reiterated that if you want to contribute to any of the CG’s projects, you need to join the group. If you represent a company working in the field of music software, it’s important that you join as a representative of your company.
SMuFL (1:01:38)
Daniel outlined the current state of SMuFL 1.4, which is not really any further forward than last year. He reiterated that issues are always welcome.
Michael Cuthbert introduced two issues concerning text SMuFL fonts. He pointed out that Bravura Text is very large because of the many combining glyphs for allowing symbols to be raised or lowered by up to 8 staff positions, and this makes the font less useful for subsetting, etc.
He also pointed out that the use of Bravura Text in user interfaces is difficult because the size of, say, a sharp relative to a treble clef means that showing them at the same point size would produce very different visual sizes. Daniel’s initial reaction was that using Bravura Text in a user interface is not necessarily an appropriate goal for text SMuFL fonts, but it’s perhaps something that we could tackle as a separate effort.
MNX (1:12:00)
Adrian introduced the MNX Common by Example page, showing that the focus has moved to building the specification around specific atomic examples rather than from the top down. When designing new features, we are now working “examples first” and coming up with analogous MusicXML code to help make it more illustrative.
Benjamin Bohl proposed adding MEI as a third column to the examples page, which Michael opposes on the grounds that we should perhaps keep focus on the formats currently maintained by the CG. Adrian agreed, and said that it’s important to keep the examples very focused for the time being.
James Ingram asked to what extent the specification can be trusted. Adrian said that the spec can be trusted, but it’s easier to understand if you look at the MNX Common by Example file.
Benjamin Bohl shared some resources that the MEI community have been working on to ease the interchange with MNX:
The Music Encoding Initiative (MEI) sees the need to better connect with the MNX community. Thus we did some work to support this. Namely providing a MEI Basic customization that fits the current development status of MNX and providing a converter for MNX to MEI.
Adrian announced that we have begun work on a tool to convert MusicXML to MNX, which was released via a new W3C repository on GitHub soon after the meeting ended.
Adrian expounded on why Python was chosen as the language. It’s popular, well-understood, and runs on every operating system. Benjamin Spratling expressed concern that it can’t run on iOS. Jim DeLaHunt and Michael pointed out that it should be possible to run the converter on a website and have an iOS app use a web service to provide conversion.
An eventual goal is to provide a production-ready two-way conversion between MusicXML and MNX. Two-way conversion will be useful to help drive adoption. It will also hopefully be possible to use it as a MusicXML “cleaner,” allowing you to ingest MusicXML and output MusicXML that uses a more consistent approach, making it easier to write MusicXML importers.
Adrian also explained the non-goals for the project, to keep it tightly focused on providing a conversion process and nothing else.
Laurent asked whether the converter provided a direct correspondence between classes and MNX elements, and Adrian confirmed that this is the case.
Peter Jonas asked why not use XSLT to provide the translation? Adrian’s hypothesis is that it’s either not possible or is possible but extremely difficult to perform the conversion using XSLT. Michael pointed out that XSLT’s strengths don’t really lie in this kind of large-scale conversion project.
Adrian reflected on his experience working on the converter before and said that he was happy to report that it feels good, and is a testament to the work done by Joe on the bones of the specification.
It is hoped that mnxconverter will help to grow understanding and appreciation for the core MNX concepts, and provides another open-source approach to MusicXML parsing.
Matt Briggs asked whether it might be possible to create XSDs directly using reflection from the Python code. Michael said that we have no XSD schema for MNX at the moment, but there will be a schema available in the future. Benjamin Bohl suggested using ODD as it can compile to XSD, RNG, and so on.
Should I Start Using MNX? (1:43:15)
Adrian said that it’s probably not yet time to start implementing MNX unless you want to be on the bleeding edge, but it’s a good idea to become more familiar with the core concepts.
MNX vs. MNX-Common (1:44:04)
Adrian provided a quick recap of the “MNX” name and how it was originally conceived as a kind of umbrella term to allow the packaging of many different types of music data. The group then talked about two different specific flavours, MNX-Common and MNX-Generic, but this is clumsy. So we propose instead renaming MNX-Common to simply MNX, and MNX-Generic to simply MGX.
Christina Noel points out that MNX-Common and MNX-Generic were names that were hard-fought and feels that renaming the formats again now is not the right time. Michael Cuthbert agreed.
Peter Jonas pointed out that people will abbreviate to MNX anyway, and this could cause confusion, and the kinds of practical issues that Adrian elucidated last year.
Jeremy Sawruk proposed perhaps keeping MNX-Generic but dropping “Common” from MNX.
James Sutton pointed out that there is at present very little in common between MNX-Common and MNX-Generic, and it’s unlikely that they’ll become more unified, so keeping the same name is itself confusing.
Start Implementation Milestone (1:53:03)
Adrian stated that the goal is to reach the milestone of the project being stable enough to be able to encourage developers to start implementing MNX-Common by the end of 2020.
Comments and Questions (1:54:30)
Daniel Ray asked whether MNX represents the best path forward. In the MIDI 2.0 specification, they have carved out some space for “notation over the wire”, and a couple of the companies in the MMA are, he says, working on this. He thinks this could be a common native format rather than a common interchange format. Michael responded, as he’s part of the Standard MIDI File 2.0 working group. The MMA community seems nowhere near as close as Daniel suggests, nor is it the best community to develop notation formats, because it doesn’t have the same concentration of expertise in the field as this W3C CG.
Benjamin Spratling asked if there were open source implementations of MusicXML that could render everywhere, such as using HTML or SVG? OpenSheetMusicDisplay, MuseScore, and Verovio were mentioned as possibilities for this, depending on just what you are looking for.
Jim DeLaHunt asked if there was already a place to discuss issues with scores as digital native documents such as formats, tools, and making editorial decisions in transcription projects, whether at the CG or elsewhere. Nobody could think of a place that was already doing this. The forums at notat.io might be the closest. W3C Community Groups don’t provide really great web tools for this type of discussion that is not related to specification and software development. Raising this as an issue on GitHub might attract some other ideas and suggestions from the community.
At the end of the meeting, 24 of the attendees had their cameras on for the group photo in the video thumbnail.
As part of the preparation for this week’s Community Group meeting, the co-chairs discussed the naming of MNX-Common and MNX-Generic. The naming is becoming more important with the project about to enter another pivotal phase.
The MNX naming scheme was proposed by former co-chair Joe Berkovitz when a key part of the plans was the notion that MNX would be a container format for a variety of symbolic music representation formats. Current co-chair Adrian pointed out the practical problems with this approach: developers and users alike would not know in advance whether a particular MNX file could be used with their application or contained the expected kind of data.
Consequently we agreed to go forward with MNX-Common and MNX-Generic, with the expectation that any further variants in the MNX family would have their own suffix. But this approach is somewhat clumsy, and the co-chairs will propose a new naming scheme at Thursday’s meeting.
MNX-Common will become simply MNX, while MNX-Generic will become MGX. There is no particular reason to define these abbreviations, but we can take the “MN” in “MNX” to stand for “Music Notation” and the “MG” in “MGX” to stand for “Music Generic”.
Community Group members will have an opportunity to respond to this proposal in Thursday’s Community Group meeting.
Community meeting preparation
The majority of the meeting was spent in reviewing the presentation planned for this Thursday’s Community Group meeting. If you wish to attend but have not yet signed up, there is still time, but you must sign up in advance so that you can be sent the Zoom meeting ID. Complete the sign-up form here.
Next meeting
The next meeting will be the Community Group meeting this Thursday, 30 April, and the next co-chair meeting will be on Tuesday 12 May.
Michael reported that we already have 30 people signed up for the forthcoming community group meeting, which will take place on Thursday 30 April 2020. If you’ve not yet signed up, please find full details here, including the sign-up form.
MusicXML 3.2 issues
Michael has been adding issues in preparation for the discussion about MusicXML 3.2, and after a brief discussion between the co-chairs in which it was agreed that these new issues should be in scope, he has added these issues to the MusicXML 3.2 milestone.
SMuFL 1.4 update
Daniel will give a short update on SMuFL progress in the online meeting in a couple of weeks. In the meantime he updated the co-chairs about some recent updates to Bravura, including retiring the SVG version of the font. There has also been a recent release of Bravura itself, bringing it to version 1.35.
Next meeting
The next co-chair meeting will be on Tuesday 28 April 2020.
With Musikmesse cancelled for 2020, we will move our annual meeting of the W3C Music Notation Community Group online this year. The meeting is scheduled for Thursday, 30 April at 2:00 pm UTC. This will be 7:00 am in San Francisco, 10:00 am in New York, 3:00 pm in London, 4:00 pm in Frankfurt, and 11:00 pm in Tokyo.
As usual we will plan for the meeting to last for 2 hours to allow plenty of time for discussion. The agenda will include:
MusicXML 3.2 kickoff
SMuFL update
MNX update
We will conduct the meeting using Zoom, the conferencing tool that we have used regularly for several years at MakeMusic. Zoom includes a feature to record meetings, so the meeting should be available afterwards for those who cannot attend live.
Please indicate your availability for the meeting by completing the signup form. It is possible that we may reschedule the meeting if we find that a large number of people cannot make the proposed date and time. Once you have signed up, we will send you a calendar invitation that includes the link to the meeting ID.
Thank you for joining us at this meeting from the safety of your own homes. We hope that all of you stay healthy in the midst of the current pandemic, and look forward to the time when we can meet in person once again.
Following the cancellation of Musikmesse 2020, we have now tentatively scheduled the virtual Community Group meeting for Thursday 30 April 2020 at 2pm UTC (3pm London / 4pm Berlin / 10am New York / 7am Los Angeles). The meeting will be held via Zoom.
If you are unable to attend at the chosen time, you can indicate another time that would be more convenient for you (though we will only consider rescheduling the meeting if a large number of attendees cannot make the original time). The meeting will be recorded and it will be possible to watch it again on demand after the event.
MusicXML 3.2 update
Michael has added a new issue #302 concerning a potential extension for piano pedaling without a specific end point. The co-chairs agreed that this should come into scope for MusicXML 3.2.
MNX-Common
Adrian has added a new section on rhythm (augmentation) dots to the MNX-Common by Example page. Adrian also had to take care of a small travis-ci issue related to the deployment of the MNX-Common by Example page.
Adrian has also created issue #174 concerning how repeat barlines and repeat endings should be encoded in MNX-Common. The co-chairs welcome feedback from the community about the proposed approach: Adrian has posed a number of specific questions and we welcome feedback on thos issues and any others arising.
Next meeting
The next co-chair meeting will be on Tuesday 14 April 2020.
