Data technologies

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.

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

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.
 

The mission of the Web Payments Working Group is to make payments easier and more secure on the Web. The group seeks to:

• streamline checkout by making it easier for users to return stored credentials and other information, and by creating a consistent experience across Web sites, browsers, and operating systems. These improvements should help reduce the percentage of transactions abandoned prior to completion ("shopping cart abandonment") by improving consumer confidence in the payment experience;
• improve payment security by fostering digital payment method innovation on the Web;
• simplify and lower the cost of creating effective Web checkout experiences;

Under its charter, the Working Group defines Recommendations that allow for a payment to be initiated within a Web site or application.

The Working Group will continue to advance these existing specifications to Recommendation:

• Payment Request API, which standardizes an API to allow merchants (i.e., Web sites selling physical or digital goods) to utilize one or more payment methods with minimal integration. User agents (e.g., browsers) facilitate the payment flow between merchant and user, mediating the user experience and providing consistency between different merchants and providers.
• Payment Method Identifiers, which defines the validation and (where applicable) registration of identifiers used for matching purposes by other W3C payments specifications.
• Payment Handler API, which defines capabilities that enable Web applications to handle payment requests. The specification defines how payment apps register their capabilities with the user agent, how the user agent communicates with them, and what information is exchanged.
• Payment Method Manifest, which allows the curators of a defined payment method or owners of a proprietary payment method to authorize (via a manifest file) which payment apps may be used to fulfill the payment method. The scope of this work extends to all types of payment apps, including native mobile apps and Web apps.

The Working Group will continue to develop the following payment method specification, intended to become a Working Group Note:

• Basic Card Payment, which specifies request and response data for making simple card payments with Payment Request API.

The Working Group will also look at enabling re-use of the Payment Request API data model in out-of-browser payments. One approach may be to define the model in a binding- and encoding-neutral way. For early work on this topic, see HTTP Messages 1.0.

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.

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.

The OASIS LegalRuleML TC defines a rule interchange language for the legal domain. The work enables modeling and reasoning that allows implementers to structure, evaluate, and compare legal arguments constructed using the rule representation tools provided.
 
The TC is affiliated with the OASIS LegalXML Member Section. For more information on LegalRuleML, see the TC Charter.

The OASIS Electronic Court Filing TC will develop specifications for the use of XML to create legal documents and to transmit legal documents from an attorney, party or self-represented litigant to a court, from a court to an attorney, party or self-represented litigant or to another court, and from an attorney or other user to another attorney or other user of legal documents.
 
The TC is affiliated with the OASIS LegalXML Member Section. For more information, see the TC Charter and FAQ

The OASIS Litigant Portal (LP) Technical Committee is chartered to produce specifications for data interoperation between Litigant Portal Modules. The technical specifications are collectively referred to as the Litigant Portal Exchange (LPX) Specifications. Portal modules are designed to provide assististance to self-represented litigants. The modules will (a) define structured interactions between related modules in the portal, (b) facilitate navigation between modules in the portal, (c) define interfaces with external partners and resources. Specifications for information exchange will initially support XML data formats. Members of the LP TC may also produce non-Standards Track content such as tutorials, usage guides, quick start guides and other documents that will assist the broader community in adopting the LPX specifications.
 
The TC is affiliated with the OASIS LegalXML Member Section. For more information on the LP TC, see the TC Charter.

OAXAL represents a method to exploit technical documentation assets by extending the usefulness of core XML-related standards in a comprehensive, open architecture. OAXAL defines a complete, automated package from authoring through translation, providing authors with a systematic way to identify, store, and reuse existing sentences. Since such sentences are likely to have been previously translated, OAXAL delivers a means to dramatically increase translation matches.