- From: W3C Community Development Team <team-community-process@w3.org>
- Date: Tue, 5 Mar 2019 17:45:18 +0000
- To: public-music-notation@w3.org
SMuFL 1.3 final report published Michael and Adrian congratulated Daniel on the publication of the spec, and the co-chairs ceremonially made their licensing commitments. Daniel agreed to write a blog post announcing the release of the report and requesting that others make their own licensing commitments. Introduction to MNX Michael and Daniel have provided feedback to Adrian on the draft of the introduction to MNX that he has written. Adrian was struggling to fit MNX-Generic into the narrative of the post and wonders whether now MNX-Generic is sufficiently different from MNX-Common that it should perhaps be a completely separate format. He has three reasons: It's confusing for users to have two kinds of MNX. Which one should users choose? How would the user understand the differences in the level of semantics between the two formats?It's confusing for developers, too. The type of development work required to parse something that is essentially an SVG wrapper versus a semantic tree-based document model is almost completely different. Adrian's guess is that the majority of developers would only want to do one of them.There's no obvious benefit in having them wrapped together in the same format apart from some negligible stuff like sharing the metadata format. Michael expressed agreement with all of these points. Part of Joe's motivation for the decision to bring MNX-Generic into the standard was to attract people from other communities, e.g. from the MEI community. But having a family of specifications maintained by the same organization may be sufficient to address that goal. This is already captured as issue #98, which the co-chairs agreed to place under active review. Michael also pointed out that the MNX names are still considered code names, so we could even decide to call them different things at the end. Daniel expressed agreement with Adrian's points. Michael said that rather than the naming issue, the more critical issue is the notion of whether MNX is a generic container format. In many ways an MNX container would be no more useful to a software application than e.g. a zip file. It would not be obvious without looking inside it what it contains and what to do with its contents. The co-chairs agreed to defer further discussion on the container format until the wider issue is settled. Adrian clarified that he thinks it's crucial to do the job of MNX-Generic but the issue is how the two formats are positioned. The co-chairs are in broad agreement that we should focus MNX on the semantic format currently known as MNX-Common and move the MNX-Generic format to a separate specification. We will invite feedback from the user community about whether we are overlooking any advantages to the current approach, for feedback about the idea of separating them, and to solicit ideas for names for a newly-separated format. Michael will slightly reorganise the order of the pages on the Wiki to make sure the spec is prominently displayed there. Adrian's introduction will be published as the README.md in the MNX repository, so it will eventually appear as the root of https://w3c.github.io/mnx. CSS in MNX Adriam raised the issue of using CSS-like styling in MNX, which is currently part of the draft specification. Although he thinks it's conceptually a beautiful idea, it will probably be impractical to embed CSS syntax directly in the format because it will require the building of a whole parallel parser. Michael agreed, and there was brief discussion about how we should take the aspects of CSS that work for us and build an XML-friendly approach that fits into the existing XML parser. We know that this was something of a controversial approach among the community for this reason anyway. The co-chairs reflected that all of the decisions that have been taken to date on MNX are still fungible, provided we have consensus from the community. Sounding vs. written pitch Adrian will review the recent discussion on issue #138 concerning sounding vs. written pitch and bring it together into a set of pros and cons. The aim is still for the co-chairs to have sufficient time to come up with a concrete proposal that takes the discussion into account ahead of the Musikmesse meeting. We aim to formalise this proposal in our next meeting in two weeks. DAISY Music Braille We haven't yet received the promised documents from the DAISY Music Braille group, which were expected on 1 March. Daniel reported that Matthias Leopold from DZB in Germany plans to attend the Musikmesse meeting. Preliminary Musikmesse meeting agenda Michael will send an email reminding people to sign up to let us know they're coming and to solicit agenda items. The current preliminary agenda looks like this: SMuFL 1.4 plans (Daniel will assemble an issue list etc.)MusicXML 3.2 plans (Michael will assemble an issue list etc.)DAISY Braille Music group and its requirements (Daniel will ask Matthias if he wants to speak)MNX topics (probably MNX-Generic vs. MNX-Common, CSS in MNX, sounding/written pitch) Michael will contact Peter Jonas at MuseScore to see if they will be able to provide an audio and/or video recording of the meeting. CLA enforcers for GitHub Adrian has done some research into CLA enforcers, and identified a number of possibilities to ensure that community members sign up to the CLA before they make contributions (definitely for pull requests, and possibly for raising issues) so we can be sure of compliance. Adrian will send the candidates to the other co-chairs for discussion, and then we'll run our proposal past our contacts at the W3C. Next meeting Our next meeting is scheduled for Tuesday 19 March. ---------- This post sent on Music Notation Community Group 'Co-Chair Meeting Minutes: March 5, 2019' https://www.w3.org/community/music-notation/2019/03/05/co-chair-meeting-minutes-march-5-2019/ Learn more about the Music Notation Community Group: https://www.w3.org/community/music-notation
Received on Tuesday, 5 March 2019 17:45:20 UTC