Information coding

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.

The OpenDocument Format (ODF) is an open XML-based document file format for office applications to be used for documents containing text, spreadsheets, charts, and graphical elements. The file format makes transformations to other formats simple by leveraging and reusing existing standards wherever possible. As an open standard under the stewardship of OASIS, OpenDocument also creates the possibility for new types of applications and solutions to be developed other than traditional office productivity applications.
 
The OpenDocument TC works closely together with the OASIS ODF Adoption Technical Committee which provide expertise and resources to educate the marketplace on the value of the OpenDocument OASIS Standard.
 
For more information, see the TC Charter and FAQ
 

The Computational Storage TWG was created for the purpose of establishing architectures and software for storage, disk, and solid state device based functionalities that allow them to be integrated with Computation in its many forms. This TWG creates software and standards that enable specific features for these devices that meet the requirements of stakeholders with these computational needs. 

The Security Assertion Markup Language (SAML), developed by the Security Services Technical Committee of OASIS, is an XML-based framework for communicating user authentication, entitlement, and attribute information. As its name suggests, SAML allows business entities to make assertions regarding the identity, attributes, and entitlements of a subject (an entity that is often a human user) to other entities, such as a partner company or another enterprise application.
 
If you are a manager looking for a high-level overview of SAML, the Executive Overview is recommended. If you are looking for a technical introduction to SAML concepts and capabilities, it is recommended to start with the Technical Overview. Additional technical information, including the complete set of SAML specifications, can be found in the knowledgebase at saml.xml.org.

The mission of the Decentralized Identifier Working Group is to standardize the DID URI scheme, the data model and syntax of DID Documents, which contain information related to DIDs that enable the aforementioned initial use cases, and the requirements for DID Method specifications.
 
The design approach for the DID specification is the same as the URI specification (RFC 3986). RFC 3986 defines the generic syntax for URIs, and all URI schemes are separate specifications. In fact, the DID specification is a conformant URI scheme. The goal of the DID specification is to do exactly the same for DIDs, that is, for this Working Group to define the generic DID specification, and then for others to define DID Method specifications.
 
The Working Group will:

1. Define the DID URI scheme.
2. Recommend a data model and syntax(es) for the expression of Decentralized Identifier Documents, including one or more core vocabularies.
3. Recommend a set of requirements for DID Method specifications that are conformant with the data model and syntax(es). The DID Method specification authoring requirements will recommend a list of mandatory and optional operations, with associated descriptions, which are expected to be defined in DID method specifications.
4. Provide a rubric of decentralized characteristics for DID Method specifications. This allows the DID Method specifications to self-certify, or independent third parties to evaluate, the DID Method specification's level of adherence to principles of decentralization.
5. Concentrate their efforts on the initial use cases with a particular focus on enabling future specification and implementation of Identity and Access Management. Use cases from other industries may be included if there is significant industry participation.
6. Define extension points enabling authentication, signing and cryptography mechanisms, but not defining specific authentication, signing, or cryptography mechanisms. (See "Out of Scope".)
7. With the initial use cases document as input, the WG will produce a NOTE at the end of the process that is a refined Use Cases document.
8. Establish a deterministic mapping between DID method identifiers and the resolution process used to resolve that DID method.

The definition of a CMDB in the context of this specification is based on the definition described in the IT Infrastructure Library (ITIL): a database that tracks and records configuration items associated with the IT infrastructure and the relationships between them. Strictly speaking, the ITIL CMDB contains a record of the expected configuration of the IT environment, as authorized and controlled through the change management and configuration management processes. The federated CMDB in this specification extends this base definition to federate any management information that complies with the specification’s patterns, schema, and interfaces, such as the discovered actual state in addition to the expected state. Typically, an administrator selects the data to be included in a CMDB by configuring the tool that implements the CMDB.

The mission of the Web Real-Time Communications Working Group is to define client-side APIs to enable Real-Time Communications in Web browsers. These APIs should enable building applications that can be run inside a browser, requiring no extra downloads or plugins, that allow communication between parties using audio, video and supplementary real-time communication, without having to use intervening servers.
 
Enabling real-time communications between Web browsers require the following client-side technologies to be available:

• API functions to explore device capabilities, e.g. camera, microphone, speakers,
• API functions to capture media from local devices (e.g. camera and microphone, but also output devices such as a screen),
• API functions for encoding and other processing of those media streams,
• API functions for accessing the data in these media streams,
• API functions for transferring data between peers,
• API functions for establishing direct peer-to-peer connections, including firewall/NAT traversal,
• API functions for decoding and processing (including echo canceling, stream synchronization and a number of other functions) of those streams at the incoming end,
• Delivery to the user of those media streams via local screens and audio output devices (partially covered with HTML5).

The working group will address issues related to using these functions in various contexts on the Web platform, such as:

• Traditional Web pages
• Web Workers of various types
• Iframes, with appropriate access controls
• Applications that span multiple pages
• Pages, workers and frames specifying content security policies or other security mechanisms that should impact the use of these APIs

The mission of the Web Platform Working Group is to continue the development of the HTML language and provide specifications that enable improved client-side application development on the Web, including application programming interfaces (APIs) for client-side development and markup vocabularies for describing and controlling client-side application behavior.
 
The group will:

• Continue the development of the HTML language, and associated APIs.
• Ensure that developers can use Web technologies to build client-side applications that rely on Web engines as application run-time environments.
• Provide generic and consistent interoperability and integration among all target formats, such as HTML, CSS, and SVG.
• Continue to define normative requirements for applications that process HTML resources, including browsers and other interactive user agents, authoring tools, content management tools, and conformance checkers.
• Ensure Web applications can work across a wide range of devices and among a broad diversity of users, in particular addressing issues of accessibility, device independence, internationalization, privacy, and security.

The mission of the Web Performance Working Group is to provide methods to measure aspects of application performance of user agent features and APIs.
 
Web developers are building sophisticated applications where application performance is a critical feature. Web developers want the ability to observe the performance characteristics of their applications, and they want the ability to write more efficient applications, using well-defined interoperable methods. Their methods must be both secure and privacy-enabling by design, using well-defined interoperable methods that conform to the current Web browser security model.
 
The Web Performance Working Group's scope of work includes user agent features and APIs to observe and improve aspects of application performance, such as measuring network and rendering performance, responsiveness and interactivity, memory and CPU use, application failures, and similar APIs and infrastructure to enable measurement and delivery of better user experience. Such deliverables will apply to desktop and mobile browsers and other non-browser environments where appropriate, and will be consistent with Web technologies designed in other working groups including HTML, CSS, Web Application Security, Web Platform, Device and Sensors, and SVG.
 
In addition to developing Recommendation Track documents, the Web Performance Working Group may provide review of specifications from other Working Groups.

The mission of the Web Fonts Working Group is to develop specifications that allow the interoperable deployment of downloadable fonts on the Web.
 
The Web Fonts WG will develop Recommendation-track specifications as listed under deliverables; track emerging implementations, and maintain communications with the typography, Web design and implementor communities.