Working group

The mission of the Audio Working Group is to add advanced sound and music synthesis capabilities to the Open Web Platform.
 
Building upon and expanding the basic functionalities brought by HTML5's and media elements and MediaStream object, the Audio Working Group defines client-side script APIs which support the features required by rich interactive applications including the ability to process and synthesize audio streams directly in script, as well as giving access to musical instruments through a bridge with existing system-level MIDI APIs.
 
The audio API provides methods to read audio samples, write audio data, create sounds, and perform client-side audio processing and synthesis with minimal latency. It also adds programmatic access to the PCM audio stream for low-level manipulation directly in script. This API can be used for interactive applications, games, 3D environments, musical applications, educational applications, and for the purposes of accessibility. It includes the ability to synchronize, visualize, or enhance sound information when used in conjunction with graphics APIs. Sound synthesis can be used to enhance user interfaces, or produce music. The addition of advanced audio capabilities to user agents presents new options to Web developers and designers, and has many accessibility opportunities and challenges that this working group will continue to keep in mind.
 
In addition to an audio processing API, this group has received feedback from the audio and music community and industry, who wish to Web-enable their MIDI-capable devices. MIDI is an electronic device interface, developed by the musical instrument industry, that includes communication protocols for two-way connection and control of a wide variety of devices, including digital musical instruments, digital audio workstations, lighting sytems, game controllers, and many other systems. The MIDI specification has wide adoption and interoperable deployment across devices and computer operating systems, and to extend this existing infrastructure, the Audio Working Group is also developing a specification to create a bridge between the browser and existing system-level MIDI APIs, to make musical instruments first-class citizens of the Web.
 
The scope of this working group includes:

• Developing a client-side script API for processing and synthesizing PCM audio streams, including direct scripted solutions.
• Access to audio devices, such as for microphones or other audio inputs, and multi-channel speakers or other audio outputs.
• APIs and advanced functionality regarding audio cache management and audio capability information.
• Defining a client-side script API for accessing and manipulating MIDI-capable devices available on the users' systems.

This working group will take into account common work-flows for sound creators, including considerations for common audio formats. This group will also liaise with other groups for direct connection to audio inputs, such as microphones and speakers.
 
The HTML5 specification introduces the

The mission of the Accessible Rich Internet Applications Working Group (ARIA WG, formerly part of the Protocols and Formats Working Group) is to develop technologies that enhance accessibility of web content for people with disabilities. This includes continued development of the Accessible Rich Internet Applications (WAI-ARIA) suite of technologies and other technical specifications when needed to bridge known gaps.
 
The scope of the working group is

• Continue development of existing ARIA specifications to address needs reported by authors and to achieve parity with native host languages, creating new ARIA specifications where necessary;
• For each ARIA specification developed by this Working Group, create a corresponding Accessibility API Mappings specification defining the correct exposure for each platform;
• For all attributes defined by this Working Group, document best practices for authors;
• Collaborate with other groups to create mapping specifications for native host language semantics;
• Develop testing tools which can be used to verify accessibility implementations by examining the mappings exposed via platform accessibility APIs;
• Collaborate with other groups involved in defining ARIA techniques and implementing ARIA support.

The mission of the Accessible Platform Architectures Working Group (APA WG) is to ensure W3C specifications provide support for accessibility to people with disabilities. The group advances this mission through review of W3C specifications, development of technical support materials, collaboration with other Working Groups, and coordination of harmonized accessibility strategies within W3C.
 
The scope of the working group is

• Support W3C Working Groups and external organizations collaborating on web technologies to create technical specifications that provide features needed for accessibility to people with disabilities:
  • Provide expertise to the W3C about the needs of users with disabilities, including both serving as a resource base and providing educational in-reach to the W3C community as needed;
  • Review W3C requirements and specifications (accessibility horizontal reviews, AHR) as needed to identify accessibility issues and make recommendations to the appropriate Working Group, particularly at the First Public Working Draft and Last Call or Candidate Recommendation stages and when explicit milestone review readiness is signaled;
  • Work closely with Working Groups when needed to help them architect their specifications to support, and not unknowingly interfere with, accessibility;
• Develop and publish explanatory information about accessibility of web technology:
  • Document concrete guidance about how to ensure technical specifications appropriately support accessibility;
  • Collect information about technology features, implementation, and usage patterns to institutionalize W3C knowledge about present-day accessibility problems, including for emerging technologies such as social networking, real-time communications, Web-based television viewing, etc.;
• Explore new technologies and accessibility challenges and begin to develop remediation approaches:
  • Leverage existing W3C markup technologies to produce new specifications or additions to existing specifications which support content personalization for various identified accessibility requirements;
  • Determine accessibility considerations for new devices and technologies, such as artificial intelligence, authentication, automotive interfaces, digital publications, graphics and media, mobile communications devices, payments, tablets, virtual and augmented and mixed reality, Web-enabled television, Web of Things, etc.;
  • Identify gaps and questions from accessibility specification reviews that may need research, and articulate findings and specific questions for discussion in various additional fora;
• Coordinate with other accessibility stakeholders (including other WAI groups, accessibility proponents in other groups, and external accessibility organizations) to develop harmonized accessibility guidance across W3C:
  • Coordinate with accessibility proponents in W3C technical groups to help ensure accessibility solutions are developed in a consistent manner across technologies and to ensure that accessibility needs are addressed at an appropriate part of the technology stack;
  • Involve accessibility proponents in other fora - such as the WAI Interest Group, community groups, coordination activities, and other centers of expertise - to maximize the knowledge and impact brought to the group's activities;
  • Advocate creation and reuse of common implementations of functions that are required by accessibility;
  • Review non-W3C technologies that impact the accessibility of W3C technologies;
  • Strategize solutions within W3C and via liaisons with external organizations.

The mission of the Accessible Rich Internet Applications Working Group is to enhance the accessibility of web content through the development of supplemental attributes, including roles, states, and other properties, that can be applied to native host language elements and exposed via platform accessibility APIs.
 
The scope of the working group is

• Continue development of existing ARIA specifications to address needs reported by authors and to achieve parity with native host languages, creating new ARIA specifications where necessary;
• For each ARIA specification developed by this Working Group, create a corresponding Accessibility API Mappings specification defining the correct exposure for each platform;
• For all attributes defined by this Working Group, document best practices for authors;
• Collaborate with other groups to create mapping specifications for native host language semantics;
• Develop testing tools which can be used to verify accessibility implementations by examining the mappings exposed via platform accessibility APIs;
• Collaborate with other groups involved in defining ARIA techniques and implementing ARIA support.

The purpose of the XDI TC is to define a format and protocol for semantic data interchange using a standard addressable semantic graph model serialized in JSON.
 
For more information, see the TC Charter and FAQ.
 
The TC operates under a standing rule approved 17 July 2008 under which the TC does not hold regular official meetings and conducts all business by electronic ballot only. Unofficial weekly meetings are held to enable discussion among members but no business is conducted nor actions taken at those meetings.

Advancing the bitext exchange standard for localisation
 
If you are using your own extension elements or attributes in XLIFF 2, and the extension has identifiers, you MUST register the prefix corresponding to your extension's namespace, so that tools can point to the element following the Fragment Identifier mechanism of XLIFF 2

Defining standard serialization-independent interchange objects for payloads and metadata to support interoperability in the Globalization, Internationalization, Localization and Translation (GILT) industries
 
The principal goal of the OASIS XLIFF Object Model and Other Serializations (XLIFF OMOS) TC is to define and further advance standards-based payload and metadata interoperability in the Globalization, Internationalization, Localization and Translation (GILT) industries. TC deliverables will describe and define standard serialization-independent interchange objects based on legacy XML standards that have been successfully used in the GILT industries. For example, the TC will define and maintain non-XML serializations of the XLIFF Object Model, including prominently a JSON serialization. TC members will define specific standard Application Programming Interfaces (APIs) and abstract service architectures for various XLIFF serializations, and for other related standards (such as TMX, TBX, ITS, SRX, etc.). The TC plans to host and maintain the Translation Memory Exchange (TMX) v1.4b (1.4.2) specification, developing and maintaining any successor versions of the TMX standard including its serialization-independent Object Model and various serializations.

Since its original publication in 2014 by the RDF 1.1 Working Group, JSON-LD 1.0 has become an essential format for describing structured data on the World Wide Web. It is estimated to be used by between 10% and 18.2% of all websites. This is due largely to its adoption as a recommended format by schema.org. It has been adopted by several Recommendations including those from the Social Web, Web Annotation, and Linked Data Platform Working Groups, and current Working Groups have expressed interest in alignment of their specifications, such as the Publishing and Web of Things Working Groups. It has provided a much-needed bridge between communities that need rich semantics, and those that desire an intuitive and easily usable format (see separate wiki page for more details).
 
The mission of the JSON-LD Working Group is to update the JSON-LD 1.0 specifications to address specific usability or technical issues based on the community’s experiences, implementer feedback, and requests for new features.
 
The JSON-LD Working Group will update the JSON-LD 1.0 Recommendation to take into account new features and desired simplifications that have become apparent since its publication. The group will also extend the JSON-LD 1.0 Processing Algorithms and API Recommendation to update the existing APIs corresponding to changes in the JSON-LD Recommendation. Additionally, the group will move the Framing API CG specification to W3C Recommendation.
 
A summary of syntax changes proposed for inclusion by the JSON for Linking Data Community Group can be found on a wiki and in slides used at TPAC 2017.
 
The work must be consistent with principles expressed in the Data on the Web Best Practices Recommendation. All changes must preserve backward compatibility for JSON-LD 1.0 documents. This means that, when processing existing JSON-LD documents, JSON-LD 1.1 processors generate the same expanded output, unless that output is subject to errata in JSON-LD 1.0 or is otherwise an unspecified implementation detail.

The mission of the Media Working Group is to develop and improve client-side media processing and playback features on the Web.
 
Standardization efforts to develop media foundations for the Web, such as the HTMLMediaElement interface and Media Source Extensions, have helped turn the Web into a major platform for media streaming and media consumption. Building on the experience gained through implementation, deployment and usage of these technologies, and on incubation discussions within the Web Platform Incubator Community Group, the Media Working Group will extend media foundations with new standardized technologies to improve the overall media playback experience on the Web.
 
The scope of the Media Working Group is:

• Detection of media capabilities
• Detection of the autoplay policy
• Statistics on perceived playback quality
• Generation of media streams for playback
• Playback of encrypted content
• Exposure of media features at the system level to Web applications (e.g. access to platform media keys, display of media metadata at the system level, creation of an always-on-top video window) to Web applications
• Exposure of metadata event tracks synchronized to audio or video media

The mission of the Pointer Events Working Group is to provide methods to enable simple device independent input from pointing devices such as mouse, pen, and multi-touch screen.
 
Web browsers can receive input in a variety of ways including mouse, touch, and pen input. A “pointer” is an abstract form of input that can be any point of contact on a input surface made by a mouse cursor, pen, finger, or multiple fingers.
 
Pointer Events provide support for handling mouse, touch, and pen input for web sites and web applications through DOM Events. For example, a content creator using Pointer Events would only have use a single model, rather than separate code paths for mouse events, touch events, and pen-tablet events, making authoring content much more efficient and inclusive.
 
This Working Group seeks to enhance the features delivered in the Pointer Events Level 1 Recommendation by exploring changes, such as:

• Addition of direction-specific values for finer-grained control of panning touch behaviors
• Reduction of hit-testing via implicit capture
• Additional clarifications of API behavior and performance optimizations

AFI WG is the leading Standardization Group on Autonomic Management & Control (AMC) of Networks and Services, including Autonomic Networking, Cognitive Networking and Self-Management. Its mandate is to carry out the various Tasks and Activities described below:

• Develop use cases and requirements for automated & autonomic (self-) management of networks and services;
• Develop test frameworks and test specifications for autonomic network architectures (Self-Adaptive Networks);
• Draft test specifications for Scenarios, Use Cases and Requirements for automated & autonomic (self-) management of networks and services;
• Drive a 5G PoC Program/Project on GANA Autonomics in 5G Network Slices Creation, Autonomic & Cognitive Management & E2E Orchestration; with Closed-Loop (Autonomic) Service Assurance of IoT 5G Slices;

Maintenance and evolution of existing ETSI standards on network and service management, including NGN management (ETSI 188 series: https://www.etsi.org/deliver/etsi_ts/188000_188099/ ); and Maintenance of existing ETSI Standards linked to AFI activities: 

• ETSI TS 103 194 on Scenarios, Use Cases and Requirements for Autonomic/Self-Managing Future Internet;
• ETSI TS 103 195-1,
• ETSI TS 103 195-2,
• ETSI TS 103 195-3

GANA Model and its instantiations onto various types of network architectures and their associated management and control architectures:

• ETSI TR 103 473 on GANA autonomics in BBF Architectures;
• ETSI TR 103 404 on GANA autonomics in 3GPP Backhaul & Core Network Architectures;
• ETSI TR 103 495 on GANA autonomics in Wireless Ad-hoc/Mesh Network Architectures;

ETSI White Paper no. 16: The Generic Autonomic Networking Architecture Reference Model for Autonomic Networking, Cognitive Networking and Self-Management of Networks and Services: http://www.etsi.org/images/files/ETSIWhitePapers/etsi_wp16_gana_Ed1_20161011.pdf

The mission of the WebAssembly Working Group is to standardize a size- and load-time-efficient format and execution environment, allowing compilation to the web with consistent behavior across a variety of implementations.
 
The scope of the WebAssembly Working Group comprises addressing the need for native-performance code on the Web in applications ranging from 3D games to speech recognition to codecs—and in any other contexts in which a common mechanism for enabling high-performance code is relevant—by providing a standardized portable, size-, and load-time-efficient format and execution environment that attempts to maximize performance and interoperate gracefully with JavaScript and the Web, while ensuring security and consistent behavior across a variety of implementations.
 
Since the inception of the Web, various technologies have been developed to allow “native” applications on the Web. Techniques such as user consent with digital signatures and Virtual Machines with different capabilities than JavaScript failed to be robust in the face of increasingly high security requirements. Later efforts like Native Client, which featured robust security, failed to achieve cross-browser adoption. Cross-compilation to JavaScript using Emscripten, especially using the machine-optimization subset called asm.js, achieved some degree of success. However, consistent cross-browser performance, shared memory threads, and other machine features have proved elusive.
 
The WebAssembly format and execution environment address the shortcomings of those previous efforts.