ISO/IEC 19845:2015 specifies the OASIS Universal Business Language (UBL), which defines a generic XML interchange format for business documents that can be restricted or extended to meet the requirements of particular industries. Specifically, UBL provides the following:
- A suite of structured business objects and their associated semantics expressed as reusable data components and common business documents.
- A library of XML schemas for reusable data components such as "Address", "Item", and "Payment", the common data elements of everyday business documents.
- A set of XML schemas for common business documents such as "Order", "Despatch Advice", and "Invoice" that are constructed from the UBL library components and can be used in generic procurement and transportation contexts.
We create standards related to testing and specification languages and provide frameworks and methodologies to enable the other ETSI committees to achieve this goal. Work is performed very closely with ETSI’s Centre for Testing and Interoperability (CTI) to develop the background material which they then use in their support of other ETSI committees as well as other relevant standardization bodies such as ITU Study Group 17. Much of work done by TC MTS has also been adapted and used beyond ETSI by other organizations, fora, and industry globally.
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 mission of the Automotive Working Group is to develop Open Web Platform specifications for application developers, including but not limited to HTML5/JavaScript, enabling Web connectivity through in-vehicle infotainment systems and vehicle data access protocols. The API is agnostic with regard to the connection used.
This group will develop service specifications for exposing vehicle data and other information around vehicle centric functions.
A common pattern will be described to unify the style the different service interfaces are using.
The specification(s) produced by this Working Group will include security and privacy considerations.
Members of the Working Group should review other working groups' deliverables that are identified as being relevant to the Working Group's mission.
Services may include but are not limited to
Vehicle Data
vehicle brand, model, year, fuel type, transmission type, steering wheel position, tire pressure, oil level, wiper position, lights, doors, windows and seat settings as well as navigation, trip computer data, climate control data, speed, RPMs, acceleration, gears, …
The mission of the Browser Testing and Tools Working Group is to produce technologies for use in testing, debugging, and troubleshooting of Web applications running in Web browsers.
The scope of the Browser Testing and Tools Working Group includes protocols and APIs for the purpose of automating testing of Web applications running in browsers—for example, to simulate user actions such as clicking links, entering text, and submitting forms.
The mission of the group is to develop and maintain CSS.
Cascading Style Sheets (CSS) is a style sheet language that allows authors and users to attach style (e.g., from fonts and spacing to filter effects and style animations) to structured documents and Web applications. By separating the presentation style from the content, CSS simplifies Web authoring and site maintenance. It supports media-specific style so that authors may tailor the presentation to different devices and capabilities.
The CSS WG develops a single deliverable, the CSS specification. It consists of the following, somewhat independent technologies, all of which are in scope for the CSS Working Group:
A syntax for associating information with elements in a structured resource, in particular HTML and SVG documents. The main part of the syntax consists of rules that associate properties + values with selectors where the selectors are expressions that match elements in the structured document, based on their position in the document or based on other information about the elements (their type, what the user has done with them, etc.)
A processing model, referred to as “cascading and inheritance,” that ensures that, given one or more style sheets and a structured document, each element in the document is associated with the full set of properties and values, no matter how short the style sheets or how long the document.
A rendering model, part of which is a model of typography, i.e., a layout model for text documents, possibly with embedded other objects and possibly involving several documents simultaneously. The model describes blocks and lines of text, characters, columns, colors, dynamic effects, etc. It also includes the presentation and behavior of UI widgets. CSS's influence over UI controls is limited to defining the look of controls in various states during interaction (valid/invalid, required, inactive, etc.), hiding/unhiding, and other local behaviors, but CSS does not itself change the state of elements and does not define how (form) elements interact with a server. (The general principle is that CSS can enhance the user's interaction with a document, but the document should ideally be functional without it.)
The CSS Object Model, a set of standard APIs, to which libraries can be written for manipulating style sheets and documents with associated style information.
The CSS WG not only develops CSS, but also checks that properties needed by other working groups and which could occur in a style sheet together with CSS properties, are compatible with CSS in general and consistent in their naming schemes. This affects properties such as those of SVG and Device Independence (such as media features).
Part of the work of the working group is also to develop test suites for the various specifications it publishes.
Another part is to maintain errata and, when needed, publish revised versions of the various specifications.
The mission of the Education and Outreach Working Group is to develop strategies and resources to promote awareness, understanding, implementation, and conformance testing for W3C accessibility standards; and to support the accessibility work of other W3C Groups.
In accordance with the WHATWG-W3C Memorandum of Understanding, this group is chartered to assist the W3C community in raising issues and proposing solutions in the WHATWG HTML and DOM workstreams, and to bring WHATWG HTML and DOM Review Drafts to Recommendation.
The community (including users, implementers, and developers) and horizontal review groups are encouraged to contribute directly to the WHATWG HTML and DOM repositories; raising issues, proposing solutions, commenting on proposed solutions, and indicating support or otherwise for proposals. In the event that a person raising an issue feels that the issue has not been fairly resolved by WHATWG, the HTML Working Group may help to explain the resolution and attempts to work with the person and the WHATWG editors to achieve consensus, as detailed in the Group work mode.
The mission of the Internationalization Working Group is to enable universal access to the World Wide Web by proposing and coordinating the adoption by the W3C of techniques, conventions, technologies, and designs that enable and enhance the use of W3C technology and the Web worldwide, with and between various different languages, scripts, regions, and cultures.
Technical issues related to internationalization and universal access across the globe. The Working Group provides advice and assistance related to internationalization, encompassing work related to international, linguistic, cultural, and writing system variations affecting W3C technologies. This advice should be provided to W3C Working Groups as early as possible in the development of specifications. The Working Group also tracks developments outside the W3C which have a bearing on the international Web, such as Unicode, IDN/ICANN issues, language tag and IRI developments at the IETF, JavaScript, etc.
Reviews and discussion of W3C technologies for internationalization issues, as these technologies develop. This encompasses a broad array of cultural, linguistic, technical and accessibility concerns. Review work may also include standards created by external standards bodies and organizations related to internationalization, if it is thought to be relevant to W3C technology. The Working Group maintains liaison relationships with these groups to ensure coordinated, consistent development of these standards.
Gathering requirements for linguistic support. The Working Group supports groups documenting typographic and other requirements for scripts and languages around the world, with a view to informing specification developers and browser/ebook implementers about what needs to be supported.
Outreach and inreach, in the forms of notes, articles, tutorials, presentations, tests and other resources to help specification writers, web masters, content authors, and others involved in developing and implementing the Web understand the issues involved and the techniques available with regard to supporting international use of Web technology.
Implementation support and guidance. The WG produces tests for international features of the Web Platform, and provides advice and support to browser/ebook implementers to assist in the adoption of those features.
The formal documents produced by the Working Group are guidelines, best practices, requirements, and the like. These are best published as Working Group Notes. The Working Group will not produce Rec-track specifications, with the exception of maintaining the following W3C Recommendations:
These specifications define data categories and their implementation as a set of elements and attributes. ITS 2 adds additional concepts that are designed to foster the automated creation and processing of multilingual Web content.
It provides authors of specifications, software developers, and content developers with a common reference for interoperable text manipulation on the World Wide Web
"Ruby" are short runs of text alongside the base text, typically used in East Asian documents to indicate pronunciation or to provide a short annotation. This specification defines markup for ruby.
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 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 Second Screen Working Group is to provide specifications that enable web pages to use secondary screens to display web content.
The scope of this Working Group is to define an API that allows a web application to request display of web content on a connected display, with a means to communicate with and control the web content from the initiating page and other authorized pages. Pages may become authorized to control the web content by virtue of sharing an origin with the originating page, explicit user permission, or other facilities provided by the user agent. The API will hide the details of the underlying connection technologies and use familiar, common web technologies for messaging between the authorized pages and the web content shown on the secondary display. The web content may comprise HTML documents, web media types such as images, audio, video, or application-specific media, depending on the capabilities of the secondary display for rendering the media. Application-specific media includes that whose type is known to the controlling page and the connected display, but not necessarily a generic HTML user agent.
The API will provide a means to identify whether requesting display on second screens is likely to be successful, i.e. whether at least one secondary screen is available for display.
The API is agnostic with regard to the display connection used, and also works with display connections that support video only, for example, a TV connected to a laptop with an HDMI connection. In such a usage scenario, the web content displayed on a connected display must be rendered and converted to video before it is sent to a second screen. The user agent may use whatever means the operating system provides to prepare and send the video to a second screen. Any interaction between the authorized web pages and the content displayed on a secondary screen would happen within the bounds of the initiating device since both the pages and the content are rendered on that same device, and only a video representation is sent to the second screen.
Alternatively, if the second screen device understands some other means of transmitting content to a display and a means of two-way message passing, the web content can be rendered by the remote device. In this scenario, a URL to the content to be displayed is sent to the secondary display to be rendered there. Because the content is rendered separately from the initiating user agent, pages hosted by other user agents may be authorized to control the remotely rendered content at the same time.
For a requested piece of web content, how and by which device the content is rendered is an implementation detail. The user agent is responsible for determining which secondary displays are compatible with the content that is requested to be shown through the API.
Sending content to a connected display creates a presentation session. Applications can create multiple presentation sessions to control multiple displays, although synchronization between them is not currently supported by the API.
The specifications produced by this Working Group will include security and privacy considerations. Specifically, the user must always be in control of privacy-sensitive information that may be conveyed through the APIs, such as the visibility or access to secondary displays.
Members of the Working Group should review other Working Groups' deliverables that are identified as being relevant to the Working Group's mission.
The mission of the Scalable Vector Graphics (SVG) Working Group is to develop and maintain SVG.
Scalable Vector Graphics (SVG) is a language that allows authors and users to describe graphics in a way which is scalable to different device resolutions, acessible, and animatable.
The SVG WG develops the SVG specifications. They consist of the following, somewhat independent technologies, all of which are in scope for the SVG Working Group:
A syntax for retained-model structured graphics. Both XML and HTML5 syntaxes are suported. Styling characteristics are CSS properties, expressed as stylesheets or as presentation attributes.
A rendering model which describes how the elements of SVG produce a graphical representation
An Object Model, a set of standard APIs, to which libraries can be written for manipulating dynamic and responsive graphics.
As a primary focus in this charter period, the group will concentrate on the stabilization and interoperability testing of the core SVG 2 specification. As part of that testing, features which are in the reference draft of SVG2 and which do not meet the stability and interoperability requirements for a Proposed Recommendation may be moved to separate specification modules, work on which would remain in scope, but at a lower priority.
As a secondary focus, the group may address modules for new graphical features for SVG, once there is broad consensus on adding each such feature to the Web Platform. The SVG Community Group (and also any other fora, such as WICG) will incubate new proposals. Once an incubated proposal is implemented and available (in nightly or testing builds) in at least one major browser, and has support from other SVG implementers, it may be adopted by the SVG Working Group. A requirements document will be used to collect together these features.
The mission of the Timed Text Working Group is to develop W3C Recommendations for media online captioning by developing and maintaining new versions of the Timed Text Markup Language (TTML) and WebVTT (Web Video Text Tracks) based on implementation experience and interoperability feedback, and the creation of semantic mappings between those languages.
This group is chartered to develop formats used for the representation of text synchronized with other timed media, like audio and video. Such formats MUST be useable for online media captioning, should be useable for described video (aka video/audio description) and should address the Media Accessibility User Requirements. Such formats MAY also be useable for broadcast production and exchange and MUST be useable in the context of HTML.
The Group SHOULD:
Publish a Recommendation for a new Timed Text Markup Language 2 (TTML2) specification. In the process of producing this new revision, the Group SHOULD:
Address any issues found during the development of a Simple Delivery Profile for Closed Captions.
Consider for adoption features from existing formats, such as CEA608 or CEA708, or developed by groups such as SMPTE, DECE and EBU.
Consider backward compatibility with TTML1 such as:
- A conforming TTML1 content document instance is a conforming TTML2 content document instance.
- A conforming TTML2 processor processes a conforming TTML1 content document instance such that the output produced by the TTML2 processor is within the variations allowed per TTML1; however, it may emit warnings if it encounters deprecated features.
Publish a Recommendation for the WebVTT language, in particular the parts that cover the syntax, semantics, and rendering of subtitles, delivery of metadata, captions, chapter markers, and textual audio descriptions for speech synthesis. The Group is expected to have a maintenance process that produces new versions of WebVTT annually, potentially adding new features to the specification. In the process of producing the specification, the Group SHOULD:
