MNX

Adrian has fixed the issues raised by Paul Overell in issue #358. One of the fixes involved changing the JSON schema to handle the identifier to be used for the lines property of the lyrics object. Adrian took the opportunity to make it possible to run JSON schema validation against all of the MNX example documents as well, as described here.

Adrian has also created pull request #359 to handle metadata for lyrics in the global object. It provides a dictionary using the lyric line identifiers as the key, a label used for reference, and the language that the lyrics are in. In future, this can be expanded to include additional information like style information. We welcome community feedback on this pull request.

We discussed some of the remaining work for lyrics, including how to encode which lines of lyrics are active in different regions of the score, and talked about the idea of “zones” as a data type to describe regions of bars, which could also become useful for encoding other types of data.

We also continued to discuss how to bring the MNX specification to a stable version 1.0, and to survey the parts of the specification that have already been completed with a view to how confident we feel that implementers would not be at risk of having to significantly rework things that they implement. We like the idea of producing a comprehensive list of notations encoded by MNX, in order both to map out comprehensively those areas yet to be specified, and also so that in the future applications can clearly document which aspects of the specification they import, export, preserve, etc.

The co-chairs will begin work on building this comprehensive list, and then open it up to the community for contribution.

Next meeting

The next co-chairs’ meeting is scheduled for Thursday 5 December 2024.

The RDF Notes Maintenance Community Group has been proposed by Jerven Bolleman:

The mission of this group is to help maintain some of the Notes originally published by the W3C Semantic Web Interest Group (now closed). This group will identify potential modifications to those Notes that account for changes to RDF, SPARQL, SHACL, OWL and other core standards, as well as the evolution of the supporting community.

Note: The original Notes were published with a document license that does not allow for derivative works without permission. The W3C staff is investigating the topic in search of an approach to enable Community Groups to evolve Specifications originally published under the W3C Document License.

This group expects to publish Specifications.

You are invited to support the creation of this group. Once the group has a total of 5 supporters, it will be launched and people can join to begin work. In order to support the group, you will need a W3C account.

Once launched, the group will no longer be listed as “proposed”; it will be in the list of current groups.

If you believe that there is an issue with this group that requires the attention of the W3C staff, please send us email on [email protected]

Thank you,
W3C Community Development Team

The Cloud-Edge-Client Coordination Community Group has been launched:

1. Goals The mission of this group is to explore mechanisms and interfaces between Cloud, Edge, and Client for computing workload offloading and orchestration. The typical use cases include AI acceleration, cloud gaming, and streaming acceleration. The goal is to explore the feasibility of defining a set of new APIs and mechanisms that enable computing workload offloading and orchestration between Cloud, Edge, and Client. It should leverage existing mechanisms as much as possible and should coordinate with related W3C working groups and other SDOs and open-source communities if necessary.

2. Scope of Work This group aims to discuss proposals for Cloud-Edge-Client coordination, including: – Use cases and requirements for Cloud-Edge-Client coordination – Proposals for APIs and mechanisms (including protocols) that enable computing workload offloading and orchestration between Cloud, Edge, and Client – Secure networking and trust model requirements in the context of edge computing and offload to edge.

3. Out of Scope The following are out of scope: Actual development of standards.

4. Success Criteria The Group will have succeeded if it can achieve the following:

– Participation from various stakeholder communities, especially from startups and innovators in the space of distributed computing; – Consensus on a standard solution architecture for workload offloading.

5. Deliverables Work items can be documents, such as specifications, technical reports, best practices and guidelines, use cases and requirements, white papers, etc. Work items can also be software, for instance test suites, samples, proof of concept work, etc. In general, all work items in scope of the group are welcome. If there are individuals who will commit to being editors for a document, the group should record agreement to accept it as a work item even if it conflicts with previous work adopted by the community. Newly-accepted work items that extend beyond the scope of this Community Group Charter will lead to a reconsideration of the Charter. The Community Group may vote to revise the Charter in order to include new work, or to determine that the proposed work is unrelated.

6. Specifications The group may produce Specifications that are not on the W3C Standards track. Development of W3C Standards should be done in appropriate Working Groups.

7. Non-Normative Reports The group may produce other Community Group Reports within the scope of this charter that are not Specifications, for instance Techinal Reports, Use Cases, Requirements, Primers, White Papers, etc.

8. Test Suites and Other Software The group MAY produce test suites to support the Specifications. Please see the GitHub LICENSE file for test suite contribution licensing information.

9. Dependencies or Liaisons The group may collaborate with other relevant groups within W3C.

10. Community and Business Group Process The group operates under the Community and Business Group Process. Terms in this Charter that conflict with those of the Community and Business Group Process are void.

As with other Community Groups, W3C seeks organizational licensing commitments under the W3C Community Contributor License Agreement (CLA). When people request to participate without representing their organization’s legal interests, W3C will in general approve those requests for this group with the following understanding: W3C will seek and expect an organizational commitment under the CLA starting with the individual’s first request to make a contribution to a group Deliverable. The section on Contribution Mechanics describes how W3C expects to monitor these contribution requests.

The W3C Code of Ethics and Professional Conduct applies to participation in this group.

11. Work Limited to Charter Scope The group will not publish Specifications on topics other than those listed under Specifications above. See below for how to modify the charter.

12. Contribution Mechanics Substantive Contributions to Specifications can only be made by Community Group Participants who have agreed to the W3C Community Contributor License Agreement (CLA). Specifications created in the Community Group must use the W3C Software and Document License. All other documents produced by the group should use that License where possible.

Community Group participants agree to make all contributions in the GitHub repo the group is using for the particular document. This may be in the form of a pull request (preferred), by raising an issue, or by adding a comment to an existing issue.

All Github repositories attached to the Community Group must contain a copy of the CONTRIBUTING and LICENSE files.

13. Transparency The group will conduct all of its technical work in public. If the group uses GitHub, all technical work will occur in its GitHub repositories (and not in mailing list discussions). This is to ensure contributions can be tracked through a software tool.

Meetings may be restricted to Community Group participants, but a public summary or minutes must be posted to the group’s public mailing list, or to a GitHub issue if the group uses GitHub.

14. Decision Process If the decision policy is documented somewhere, update this section accordingly to link to it. This group will seek to make decisions where there is consensus. Groups are free to decide how to make decisions (e.g. Participants who have earned Committer status for a history of useful contributions assess consensus, or the Chair assesses consensus, or where consensus isn’t clear there is a Call for Consensus [CfC] to allow multi-day online feedback for a proposed course of action). It is expected that participants can earn Committer status through a history of valuable contributions as is common in open source projects. After discussion and due consideration of different opinions, a decision should be publicly recorded (where GitHub is used as the resolution of an Issue). If substantial disagreement remains (e.g. the group is divided) and the group needs to decide an Issue in order to continue to make progress, the Committers will choose an alternative that had substantial support (with a vote of Committers if necessary). Individuals who disagree with the choice are strongly encouraged to take ownership of their objection by taking ownership of an alternative fork. This is explicitly allowed (and preferred to blocking progress) with a goal of letting implementation experience inform which spec is ultimately chosen by the group to move ahead with. Any decisions reached at any meeting are tentative and should be recorded in a GitHub Issue for groups that use GitHub and otherwise on the group’s public mail list. Any group participant may object to a decision reached at an online or in-person meeting within 7 days of publication of the decision provided that they include clear technical reasons for their objection. The Chairs will facilitate discussion to try to resolve the objection according to this decision process.

It is the Chairs’ responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favour or discriminate against any group participant or their employer.

15. Amendments to this Charter The group can decide to work on a proposed amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass. The group may make simple corrections to the charter such as deliverable dates by the simpler group decision process rather than this charter amendment process. The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.

In order to join the group, you will need a W3C account. Please note, however, that W3C Membership is not required to join a Community Group.

This is a community initiative. This group was originally proposed on 2024-11-19 by Dapeng(Max) Liu. The following people supported its creation: Dan Druta, Zoltan Kis, Chris Needham, Dapeng(Max) Liu and Sudeep Divakaran. W3C’s hosting of this group does not imply endorsement of the activities.

The group must now choose a chair. Read more about how to get started in a new group and good practice for running a group.

We invite you to share news of this new group on social media and other channels.

If you believe that there is an issue with this group that requires the attention of the W3C staff, please email us at [email protected]

Thank you,
W3C Community Development Team

Having published the Web Thing Protocol Use Cases & Requirements community group report, the Web Thing Protocol Community Group has begun work on the first of its core deliverables: the Web Thing Protocol WebSocket Sub-protocol specification.

This specification is intended to facilitate the incubation of a dedicated real-time protocol for the Web of Things (WoT), to enable a WoT Consumer to communicate with one or more WoT Things over a WebSocket connection in order to monitor and control connected devices over the Web.

The Web of Things (WoT) is a collection of standardised technology building blocks that help provide interoperability on the Internet of Things (IoT). The WoT Thing Description specification defines a metadata format for describing the capabilities of “Things” (connected devices) on the Web. The WoT Discovery specification defines mechanisms for discovering Things on the Web. This specification complements those building blocks by incubating a dedicated real-time protocol for communicating with Things over the Web.

The intention is for this specification to eventually join a standards track at the W3C or another standards body.

Following a significant number of comments from Community Group members on an initial strawman proposal, we have now started work on the formal community group report.

We encourage contributions to that report on GitHub, in the form of issues and pull requests.

If you are interested in contributing to or implementing the Web Thing Protocol in your product, service or project we welcome you to join the Community Group and share your “intent to implement” on our public mailing list.

You are also welcome to join the #web-thing-protocol Discord channel to chat about our work.

The Cloud-Edge-Client Coordination Community Group has been proposed by Dapeng(Max) Liu:

1. Goals The mission of this group is to explore mechanisms and interfaces between Cloud, Edge, and Client for computing workload offloading and orchestration. The typical use cases include AI acceleration, cloud gaming, and streaming acceleration. The goal is to explore the feasibility of defining a set of new APIs and mechanisms that enable computing workload offloading and orchestration between Cloud, Edge, and Client. It should leverage existing mechanisms as much as possible and should coordinate with related W3C working groups and other SDOs and open-source communities if necessary.

2. Scope of Work This group aims to discuss proposals for Cloud-Edge-Client coordination, including: – Use cases and requirements for Cloud-Edge-Client coordination – Proposals for APIs and mechanisms (including protocols) that enable computing workload offloading and orchestration between Cloud, Edge, and Client – Secure networking and trust model requirements in the context of edge computing and offload to edge.

3. Out of Scope The following are out of scope: Actual development of standards.

4. Success Criteria The Group will have succeeded if it can achieve the following:

– Participation from various stakeholder communities, especially from startups and innovators in the space of distributed computing; – Consensus on a standard solution architecture for workload offloading.

5. Deliverables Work items can be documents, such as specifications, technical reports, best practices and guidelines, use cases and requirements, white papers, etc. Work items can also be software, for instance test suites, samples, proof of concept work, etc. In general, all work items in scope of the group are welcome. If there are individuals who will commit to being editors for a document, the group should record agreement to accept it as a work item even if it conflicts with previous work adopted by the community. Newly-accepted work items that extend beyond the scope of this Community Group Charter will lead to a reconsideration of the Charter. The Community Group may vote to revise the Charter in order to include new work, or to determine that the proposed work is unrelated.

6. Specifications The group may produce Specifications that are not on the W3C Standards track. Development of W3C Standards should be done in appropriate Working Groups.

7. Non-Normative Reports The group may produce other Community Group Reports within the scope of this charter that are not Specifications, for instance Techinal Reports, Use Cases, Requirements, Primers, White Papers, etc.

8. Test Suites and Other Software The group MAY produce test suites to support the Specifications. Please see the GitHub LICENSE file for test suite contribution licensing information.

9. Dependencies or Liaisons The group may collaborate with other relevant groups within W3C.

10. Community and Business Group Process The group operates under the Community and Business Group Process. Terms in this Charter that conflict with those of the Community and Business Group Process are void.

As with other Community Groups, W3C seeks organizational licensing commitments under the W3C Community Contributor License Agreement (CLA). When people request to participate without representing their organization’s legal interests, W3C will in general approve those requests for this group with the following understanding: W3C will seek and expect an organizational commitment under the CLA starting with the individual’s first request to make a contribution to a group Deliverable. The section on Contribution Mechanics describes how W3C expects to monitor these contribution requests.

The W3C Code of Ethics and Professional Conduct applies to participation in this group.

11. Work Limited to Charter Scope The group will not publish Specifications on topics other than those listed under Specifications above. See below for how to modify the charter.

12. Contribution Mechanics Substantive Contributions to Specifications can only be made by Community Group Participants who have agreed to the W3C Community Contributor License Agreement (CLA). Specifications created in the Community Group must use the W3C Software and Document License. All other documents produced by the group should use that License where possible.

Community Group participants agree to make all contributions in the GitHub repo the group is using for the particular document. This may be in the form of a pull request (preferred), by raising an issue, or by adding a comment to an existing issue.

All Github repositories attached to the Community Group must contain a copy of the CONTRIBUTING and LICENSE files.

13. Transparency The group will conduct all of its technical work in public. If the group uses GitHub, all technical work will occur in its GitHub repositories (and not in mailing list discussions). This is to ensure contributions can be tracked through a software tool.

Meetings may be restricted to Community Group participants, but a public summary or minutes must be posted to the group’s public mailing list, or to a GitHub issue if the group uses GitHub.

14. Decision Process If the decision policy is documented somewhere, update this section accordingly to link to it. This group will seek to make decisions where there is consensus. Groups are free to decide how to make decisions (e.g. Participants who have earned Committer status for a history of useful contributions assess consensus, or the Chair assesses consensus, or where consensus isn’t clear there is a Call for Consensus [CfC] to allow multi-day online feedback for a proposed course of action). It is expected that participants can earn Committer status through a history of valuable contributions as is common in open source projects. After discussion and due consideration of different opinions, a decision should be publicly recorded (where GitHub is used as the resolution of an Issue). If substantial disagreement remains (e.g. the group is divided) and the group needs to decide an Issue in order to continue to make progress, the Committers will choose an alternative that had substantial support (with a vote of Committers if necessary). Individuals who disagree with the choice are strongly encouraged to take ownership of their objection by taking ownership of an alternative fork. This is explicitly allowed (and preferred to blocking progress) with a goal of letting implementation experience inform which spec is ultimately chosen by the group to move ahead with. Any decisions reached at any meeting are tentative and should be recorded in a GitHub Issue for groups that use GitHub and otherwise on the group’s public mail list. Any group participant may object to a decision reached at an online or in-person meeting within 7 days of publication of the decision provided that they include clear technical reasons for their objection. The Chairs will facilitate discussion to try to resolve the objection according to this decision process.

It is the Chairs’ responsibility to ensure that the decision process is fair, respects the consensus of the CG, and does not unreasonably favour or discriminate against any group participant or their employer.

15. Amendments to this Charter The group can decide to work on a proposed amended charter, editing the text using the Decision Process described above. The decision on whether to adopt the amended charter is made by conducting a 30-day vote on the proposed new charter. The new charter, if approved, takes effect on either the proposed date in the charter itself, or 7 days after the result of the election is announced, whichever is later. A new charter must receive 2/3 of the votes cast in the approval vote to pass. The group may make simple corrections to the charter such as deliverable dates by the simpler group decision process rather than this charter amendment process. The group will use the amendment process for any substantive changes to the goals, scope, deliverables, decision process or rules for amending the charter.

You are invited to support the creation of this group. Once the group has a total of 5 supporters, it will be launched and people can join to begin work. In order to support the group, you will need a W3C account.

Once launched, the group will no longer be listed as “proposed”; it will be in the list of current groups.

If you believe that there is an issue with this group that requires the attention of the W3C staff, please send us email on [email protected]

Thank you,
W3C Community Development Team

Hi all!

Dear members of the HTML Vocabulary Community Group,

We are pleased to invite you to our next meeting, scheduled for Wednesday, 11th December, from 19:00–21:00 CET (Central European Time, UTC+1) [13:00–15:00 EST].

Agenda:

1. Presentation of the Draft Report
   
   We will present a draft report of the RDF-based HTML vocabulary, so that you are able to give feedback on the report. See for the current status the following link to the Github repository. Under the folder Specification, you will find not only the turtle serialization of the vocabulary but also a HTML file containing the current version of the draft report. The vocabulary itself is ready and functioning! This is demonstrated by two things:
   
   (1) the use of the latest version of the HTML vocabulary within the Dutch ministry of Finance to generate the budget tables for the formal budget bills of law;
   
   (2) the draft report that is generated by the HTML vocabulary itself, through the open source tool OntoReSpec.
   
   Currently, we are still finishing some details of the draft report, like a diagram of the vocabulary and some paragraphs on the structure of the vocabulary, but most of the report is finished as well. Both the vocabulary and the report are open for your feedback though! Comments, criticisms and compliments are all welcome
   
   
2. Discussion on a Showcase Event
   
   We will explore organizing a showcase event for a broader audience. This open-invite event aims to share the draft report and vocabulary, raising awareness of the existence of the vocabulary, its meaning and methodology. In addition, we aim to gather further valuable feedback.
   
   
3. How to proceed from here
   
   We will also discuss how to proceed from this point. What do we still want and need to achieve as a community group? How can we start a formal W3C working group trajectory? Which open points of the vocabulary are there to address within the current community group and which ones in a W3C working group?
   
   
4. Questions and comments
   
   

Please mark your calendars! A separate calendar invite will be sent. We look forward to your participation and insights as we progress with this important work. Only with your presence we can take the next step in helping organisations and individuals to get a better grasp of their information products.

Best regards,
Flores Bakker
HTML Vocabulary Community Group Chair

The Captured Surface Control API which was originally incubated in this community group has now been adopted to the WebRTC Working Group. Thank you all who have contributed. Your continued feedback in the specification’s new home would be much appreciated – issue have migrated here.

(The origin trial in Chrome continues – sign up is possible here.)

Participants

Umut Gültekin, Robin Whittleton, Sander Nijsingh, Christer Janzon, Thomas Nielsen, Miia Kirsi, Erik Gustafsson Spagnoli.

Agenda

1. Discuss our approach: How can we benefit from researching, discussing, and learning about the differences and connections between EN 301 549 and WCAG?
2. Plan future efforts: What specific questions or areas should we prioritize in our study group?
3. Collaborate effectively: How can we ensure that our discussions contribute to the broader understanding of accessibility standards?

Whether you’ve been working with these standards for a while or are just beginning to explore them, we encourage everyone to join the discussion. This session will be a collaborative effort to outline the goals and methods of our study group, and your input will help shape the direction we take.

Meeting notes

1. EAA, hard to know what to test in the EN-standard. 11.7 User preferences https://accessible.canada.ca/en-301-549-accessibility-requirements-ict-products-and-services-11-software#_Toc66969652
   • Sander: Badly written and hard to test.
   • Robin: Unit measurement, inches vs cm, currency etc.
     • Very complex when two currencies needs to be displayed.
   • Color
     • High contrast, Dark mode are included in EN-standard.
   • If you fail Name, Role Value – why fail both that and EN 11.5.2.5 Object information?
   • Has any one compared reports from different countries?
     • In the Netherlands they test only for WCAG as of now and not the EN standard.
   • A lot harder demands on documents in Canada and assembly manuals for IKEA now needs ALT-texts (where they are today just images without translated texts).
2. Sander shared how they do for consensus in the Netherlands. https://github.com/WCAG-Audit-Discussions/NL-BE
3. Miia shared the government agency for monitoring the current and upcoming directive https://www.tillganglighetskrav.fi/
4. Discussion topics going forward:
   • Units of measurements – talk more about this.
   • Look at copies of tests from Nordic countries and compare. What do they fail and do they explain the fail and so on?
     • It would be great if we as a group could have a consensus on fails and non fails.
   • Additions to the differences in countries applying more for the EAA apart from the standard.
   • Set up a repo like the Netherlands.
   • How does the accessibility documentation (statements) look like in the different EU countries. Create a Github issue.
   • EN-standard updates, how do we keep track?

Conclusion

There’s a lot of uncertainty of different monitoring bodies in different countries. How to know where they are, how they will fail, what kind of documentation do they demand? There also seems to be differences in the accessibility community in views of what is included and not. Our main suggestion on going forward is to set up a Github repo so we all can share the effort of documenting, adding questions and discussing EN and WCAG topics for the Nordic countries. By this we will slowly but surely find a common ground on how to test, what to test and have a common place for information about monitoring.

Erik GS and Sander will set this up together and share with the rest of the group when we can start collaborating.

The next meeting will be Thursday, November 7th at 15:00 UTC. Meeting in Local Times

• PST: 7:00 AM
• CST: 9:00 AM
• EST: 10:00 AM
• United Kingdom: 3:00PM
• Berlin: 4:00 PM
• Israel: 5:00 PM
• India: 8:30 PM

Here is a UTC to timezone converter if needed. 

As time zones can change (e.g. daylight savings), please feel free to use this link to place a calendar hold. This calendar hold should automatically adjust to the correct time for your timezone. Please note that this will not have the zoom link in the calendar hold. The zoom link is posted in the community slack channel.

If you would like another timezone translated into local time, please let Aditya Bikkani, Ciara (Kiki) Salmon or Jamie Knight know.

Meeting join information: w3.org/2017/08/telecon-info_coga-cg (opens in a new tab)

Check the meeting time in your timezone: worldtimeserver.com/convert_time_in_UTC.aspx 

Meeting Agenda

1. Welcome (Meeting notes) (5 minutes)
   1. Identify scribe for meetings notes
2. Discuss pending matters from previous meeting (20-40 minutes)
   1. [Kiki] Heads up! Rain is going to attend December 5th meeting for TPAC updates. 
   2. [Anya] Resource list brainstorm/feedback
   3. Social media brainstorm ideas + get time on calendar for social media meeting
   4. If time: [Anya] Modelling W3C documentation (with a very brief mention of AI)

Closing questions, adding any items to next month agenda and next steps (5 minutes)

The video link is shared in the slack channel. Direct link to join the slack channel: https://join.slack.com/t/w3ccogacommunitygroup/shared_invite/zt-1j4mjcois-buF7SqC9JwkUixWYffHC4Q

IoT service platform from Pingday + Diwise from Masarin/Sundsvall/Gothenburg/Sambruk

In 2024, we focus on market overview of general horizontal IoT platforms for municipalities and regions. Supplemented by reports from standardization, other important initiatives and discussions about interesting related topics and issues.

This time we get a presentation of:

1. The IoT service platform from Pingday AB, a wholly owned subsidiary of Öresundskraft AB and the City of Helsingborg. Pingday is also running “StadshubbsAlliansen” which is an association of 17 City Hubs in Sweden covering 54 municipalities.
2. The Open Source IoT Platform Diwise. The municipalities of Sundsvall and Gothenburg and other cities cooperate with Sambruk and the company Masarin.

As before, we conduct these meeting as hybrid meetings. You can participate by Zoom or physically on site. If you participate in person, please let me know if you like to join a common lunch, 11.30 at Internetstiftelsen. I´ll be happy to send you an invite.  

Zoom: https://iec.zoom.us/j/96221236876?pwd=VUkwdmlGbyt4T2wrOHNvMjdVNWVZZz09

Physical presence: Floor 1 , Gradangen, Goto 10, Internetstiftelsen, Hammarby Kaj 10D, 120 07 Stockholm. Goto 10 Stockholm | Goto 10

Meeting time: 13.00 – 15.30 CET with possibility to stay until 17.00 for those attending in person. Be most welcome either on Zoom or in person!

Preliminary agenda

13.00 – 13.10 Introduction – Tobbe

Welcome + info about the Working Group, for new participants

13.10 – 14.10 Presentation of the IoT service platform from Pingday

We get a presentation of the IoT service platform from Pingday.

14.10 – 14.15 Break

14.15 – 15.15 Presentation of the IoT platform Diwise

We get a presentation of the Open Source IoT platform Diwise.

15.15 – 15.30 Finish

• Upcoming meetings of the Working Group

• Reports from standardization

• Any other questions

Please forward this invitation if you know anyone else who might be interested.

/Tobbe