Information coding

Available (84)

Showing 49 - 60 per page



Web Applications Working Group (WebApps WG)

The mission of the Web Applications Working Group (WebApps WG) is to produce specifications that facilitate the development of client-side web applications.
 
The scope of the WebApps Working Group is:

  • Haptic input devices and their emitted events and/or data.
  • Textual input and text manipulation.
  • Data sharing across remote and local web applications.
  • Receiving and acting upon data from remote sources.
  • Accessing the file system and persistent storage.
  • Interfacing with OS capabilities.
  • Integrating web applications with the OS.

The working group also maintains a specification for mapping HTML elements and attributes to platform accessibility APIs, and a separate specification that defines author conformance requirements for setting ARIA attributes. The Working Group does not expect to add any other specifications relating to this matter.
 
Specifications produced by the WebApps Working Group enable developers to create web applications that work across a wide range of platforms and devices, and for a broad diversity of users, by addressing matters of accessibility, device independence, internationalization, privacy, and security.

Verifiable Claims Working Group

It is currently difficult to express banking account information, education qualifications, healthcare data, and other sorts of machine-readable personal information that has been verified by a 3rd party on the Web. These sorts of data are often referred to as verifiable claims. The mission of the Verifiable Claims Working Group is to make expressing, exchanging, and verifying claims easier and more secure on the Web. This charter focuses on use cases for education.
 

This initial charter for the Verifiable Claims Working Group will focus on use cases for education, and will place a strong emphasis on security and privacy. In particular, the Working Group will make a detailed analysis of threats to privacy and how they may be mitigated. As experience is gained, it is expected that future revisions to this charter will expand the scope to a broader range of use cases.
 
The Working Group will:
  1. Recommend a data model and syntax(es) for the expression of verifiable claims, including one or more core vocabularies.
  2. Create a note specifying one or more of
    1. how these data models should be used with existing attribute exchange protocols;
    2. a suggestion that existing protocols be modified;
    3. a suggestion that a new protocol is required.
  3. Focus their efforts on the identified use cases with a particular focus on the education sector. As a secondary focus, the group may address use cases on digital offers, receipts, and loyalty programs; discussion of these topics is not exclusive to this Working Group. Use cases from other industries may be included if there is significant industry participation.

Timed Text Working Group

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:

  1. Publish a Recommendation for a new Timed Text Markup Language 2 (TTML2) specification. In the process of producing this new revision, the Group SHOULD:
    1. Address any issues found during the development of a Simple Delivery Profile for Closed Captions.
    2. Consider for adoption features from existing formats, such as CEA608 or CEA708, or developed by groups such as SMPTE, DECE and EBU.
    3. 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.
    4. Facilitate mapping to HTML5/CSS3.
    5. Should address the Media Accessibility User Requirements.
  2. Publish Recommendations of new versions of TTML Profiles for Internet Media Subtitles and Captions 1.0.1 (IMSC1.0.1) and TTML Profiles for Internet Media Subtitles and Captions 1.1 (IMSC1.1) specifications subtitle and caption delivery applications worldwide, including dialog language translation, content description, captions for the deaf and hard of hearing, based on TTML Profiles for Internet Media Subtitles and Captions 1.0 (IMSC1), W3C Recommendation 21 April 2016.
  3. 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:
    1. Address any issues found in WebVTT: The Web Video Text Tracks Format produced by the Web Media Text Tracks Community Group. Some may be deferred to future versions.
    2. Address the Media Accessibility User Requirements.
  4. Maintain TTML1 and IMSC1 Recommendations as needed.
  5. Produce other technical reports (Notes) on aspects of TTML processing as appropriate.
  6. Liaise with other organisations including but not limited to those listed in § 3.2.
  7. Investigate caption format requirements for 360 Degree, AR and VR video content.

Scalable Vector Graphics (SVG) Working Group

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.

Publishing Working Group

The mission of the Publishing Working Group is to enable all publications—with all their specificities and traditions—to become first-class entities on the Web. The group will provide the necessary technologies on the Open Web Platform to make the combination of traditional publishing and the Web complete in terms of accessibility, usability, portability, distribution, archiving, offline access, and reliable cross referencing.
 
The WG will specify Web Publications and identify what they need the underlying Web platform to provide. It will build upon existing platform technologies specified by other groups, where available, seeking to fill gaps by assuring that the unique requirements of Web Publications are addressed by features (including optional features) or extension points in those specifications.
 
In particular, the WG will make normative Recommendations for Web Publications; Packaged Web Publications; EPUB 4; and DPUB-ARIA 2.0, as described in Deliverables.
 
Recommendation-track deliverables will contain mechanisms to make Web Publications accessible to a broad range of readers with different needs and capabilities. This includes general Web Content Accessibility Guidelines (WCAG) and Web Accessiblity Initiative (WAI) requirements of the W3C as well as requirements for international readers using different scripts and document formats. Profiles of Web Publications may be defined with more stringent accessibility requirements.

OASIS LegalDocumentML (LegalDocML) TC

The OASIS LegalDocML TC works to advance worldwide best practices for the use of XML within a Parliaments', Assembly's or Congress' document management processes, within courts' and tribunals' judgment management systems, and generally in legal documents including contracts. The work is based on the Akoma Ntoso-UN project. The LegalDocML TC's goal is to collect requirements from the community of the stakeholders who create, manage and use legislative and legal documents (editors, libraries, public institutions, tribunals, publishers, etc.) in order to extend and refine the standard. All are welcome to join this work.
 
The LegalDocumentXML Specs provides a common legal document standard for the specification of parliamentary, legislative and judicial documents, for their interchange between institutions anywhere in the world and for the creation of a common data and metadata model that allows experience, expertise, and tools to be shared and extended by all participating peers, courts, Parliaments, Assemblies, Congresses and administrative branches of governments. The standard aims to provide a format for long-term storage of and access to parliamentary, legislative and judicial documents that allows search, interpretation and visualization of documents.
 
The specifications of the standard is based on the experience of the Akoma Ntoso language, and for this reason the specification keeps the name "Akoma Ntoso" and the root of the XML-schema will be "akomaNtoso".
 
The LegalDocumentXML Specs examine the relationships between the proposed XML vocabulary and other similar efforts especially those that already have gained national acceptance or are included in other LegalXML vocabularies (e.g. eContracts). In particular, the CEN Metalex standard is recognized as offering a conceptual meta-model that is appropriate for the management of the compliancy issues between different XML national standards. Akoma Ntoso is from the very beginning compliant with CEN Metalex as an explicit design choice. CEN Metalex compliancy will be considered as the first and most important requirement for comparison between the XML language approved by the TC and any other XML standard.
 
One of the topics about whom the LegalDocumentXML Specs provides a standardization is a URI-based syntax for legal citations for all types of documents produced by Parliaments and Courts and managed by the XML vocabulary, called the naming convention. The LegalDocumentXML Spec aims to examine and, as much as possible, accept past experiences and decisions of the Akoma Ntoso technical team, which have been consistently using an http-based syntax. This approach appears similar to the one chosen by the European Legislation Identifier and is also consistent with the http based URIs of the URN:LEX syntax, appendix D.
 
The TC is affiliated with the OASIS LegalXML Member Section. For more information on LegalDocML, see the TC Charter.

Device and Sensors Working Group

The mission of the Device and Sensors Working Group is to create client-side APIs that enable the development of Web Applications that interact with device hardware, sensors, services and applications such as the camera, microphone, proximity sensors, native address books, calendars and native messaging applications.
 
The scope of this Working Group is the creation of API specifications for a device’s services that can be exposed to Web applications. Services include sensors, media capture, network information and discovery. Devices in this context include desktop computers, laptop computers, mobile Internet devices (MIDs), cellular phones, TVs, cameras and other connected devices.
 
Hardware security services are out of scope for this group.
 
Priority will be given to developing simple and consensual APIs, leaving more complex features to future versions.

Distributed Tracing Working Group

The mission of the Distributed Tracing is to define standards for interoperability between tracing tools.
Modern cloud-native applications are highly distributed and often span multiple technology and vendor boundaries. The complexity of these applications requires a detailed understanding of how individual requests are executed. This is referred to as "tracing".
Tracing tools for collecting this information have been available for quite some time. However, these tools have not been built with interoperability in mind. This leaves the developer with a number of challenges in getting an end-to-end trace of complex transactions:

  • Traces are often broken, because trace context information is lost in a contributing tier or the trace is restarted
  • Vendors cannot pass proprietary information across tiers instrumented with a different implementation and therefore lose relevant information (e.g. step count, server information, ...)
  • End users don't have the ability to create complete end-to-end traces of application transactions which are monitored by different tools, as there is no defined data format and semantics for trace data

The scope of this working group is the definition of data formats and headers enabling the propagation and correlation of tracing data across different implementations.

HTML Working Group

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.

Immersive Web Working Group

The mission of the Immersive Web Working Group is to help bring high-performance Virtual Reality (VR) and Augmented Reality (AR) (collectively known as XR) to the open Web via APIs to interact with XR devices and sensors in browsers.
 
The Immersive Web Working Group will develop standardized APIs to provide access to input and output capabilities commonly associated with XR hardware such as Google’s Daydream, the Oculus Rift, the Samsung GearVR, the HTC Vive, and Windows Mixed Reality headsets and sensors as well as mobile handheld devices and standalone headsets such as the Oculus Go. The WG will develop APIs to enable the creation of XR web experiences that are embeddable in the Web of today, enabling progressive enhancement of existing sites.
 
The scope of the Immersive Web Working Group charter is to define APIs which:

  • Detect available XR devices and sensors.
  • Query XR devices for device-specific capabilities.
  • Receive updated information about the device's position and orientation over time.
  • Receive updated information about the device's environment.
  • Present imagery to the device at the device's native frame rate, using the device’s position and orientation over time to provide an immersive experience.
  • Provide information about XR-specific input, including tracked controller state and hand gesture.
  • For augmenting reality on devices which support AR, enable XR sessions that provide real-world display, and provide the ability to hit-test surfaces in the real world.

Internationalization Working Group

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:
 
Internationalization Tag Set (ITS) Version 1.0 and Version 2.0

  • 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.

Character Model for the World Wide Web 1.0: Fundamentals

  • It provides authors of specifications, software developers, and content developers with a common reference for interoperable text manipulation on the World Wide Web

Ruby Annotation

  • "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.

JSON-LD Working Group

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.