OASIS

The OASIS WS-BRSP TC maintains WS-I (Web Services Interoperability) Basic Profiles (1.2 and 2.0), Basic Security Profile (1.0), Reliable Secure Profile (1.0), and ISO/IEC JTC 1 Profile Specifications (ISO/IEC 29361:2008 standard Information technology - Web Services Interoperability - WS-I Basic Profile Version 1.1, ISO/IEC 29362:2008 standard Information technology - Web Services Interoperability - WS-I Attachments Profile Version 1.0, ISO/IEC 29363:2008 document Information technology - Web Services Interoperability - WS-I Simple SOAP Binding Profile Version 1.0)..

The OASIS WS-Calendar TC works to adapt existing calendaring standards (used in human interactions) for Web services. WS-Calendar is designed for use inside other specifications and standards, bringing a common scheduling and performance allignment to service coordination, including between domains. The Committee bases its initial work on the iCalendar (IETF RFC 5545) XML serialization specification from CalConnect.
 
One of the most fundamental components of negotiating services is agreeing when something should occur, and in auditing when they did occur. Short running services have traditionally been handled as if they were instantaneous, and thereby dodged this requirement through just-in-time requests. Longer running processes may require significant lead times. When multiple long-running services participate in the same business process, it may be more important to negotiate a common completion time than a common start time. Central coordination of such services reduces interoperability as it requires the coordinating agent to know the lead time of each service.
 
Other processes may have multiple and periodic occurrence. Identical processes may need to be requested on multiple schedules. Other processes must be requested to coincide with or avoid human interactions. An example is a process that occurs on the first Tuesday of every month. Others may need to be completed on schedules that vary by local time zone.
 
Physical processes are now being coordinated by web services. Building systems and industrial processes are operated using a variety of building- and industrial-automation protocols. Energy use in buildings can be reduced while improving performance if building systems are coordinated with the schedules of the buildings occupants.
 
An increasing number of specifications envision synchronization of processes through mechanisms including broadcast scheduling. Efforts to build an intelligent power grid (or smart grid) rely on coordinating processes in homes, offices, and industry with projected and actual power availability, including different prices at different times. Two active OASIS Technical Committees require a common means to specify schedule and interval: Energy Interoperation (EITC) and Energy Market Information Exchange (EMIX). Emergency management coordinators wish to inform geographic regions of future events, such as a projected tornado touchdown, using EDXL. These efforts would benefit from a common standard for transmitting schedule and interval.
 
For human interactions and human scheduling, the well-known iCalendar format is used. Today, there is no equivalent standard for web services. As an increasing number of physical processes are managed by web services, the lack of a similar standard for scheduling and coordination of 34 services becomes critical.

The goal of WS-Calendar is to adapt the existing specifications for calendaring and apply them to develop a standard for how schedule and event information is passed between and within services. The standard should adopt the semantics and vocabulary of iCalendar for application to the completion of web service contracts.

A calendar event without an associated contract is of little use. The anticipated use of the WS-Calendar specification is as a component to be used within other specifications, bringing a common scheduling function to diverse interactions in different domains.

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.

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

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.

The OASIS PKCS 11 Technical Committee develops enhancements to improve the PKCS #11 standard for ease of use in code libraries, open source applications, wrappers, and enterprise/COTS products: implementation guidelines, usage tutorials, test scenarios and test suites, interoperability testing, coordination of functional testing, development of conformance profiles, and providing reference implementations.

The design of Test Assertions (TAs) associated with a specification or standard - referred to in this charter as target specification - has the following recognized benefits: (i) it improves the quality of this specification during its design, and (ii) it reduces the lead time necessary to create a test suite for this specification.
 
A test assertion (TA), also sometimes defined as test specification, is understood in this charter with the following general meaning: A TA is an independent, complete, testable statement for requirements in the specification. A TA always refers to an item under test (IUT), which is assumed to implement all or parts of the target specification, so that this IUT is concerned with the requirements addressed by the TA. This reference is either implicit or explicit if it is necessary that the TA identifies the item under test in some unambiguous manner. A TA describes the expected output or behavior for the item under test within specific operation conditions, in a way that can be measured or tested. A TA may refer to a test harness architecture, of which a description limited to the interactions between its components and the IUT may be sufficient. Test assertions are generally different from test cases, which are more detailed and contingent to a concrete test framework: TAs are the basis to write test cases, and relate the latter to the narrative of the target specification.
 
The general objective served by this TC is to facilitate the creation and usage of test assertions by any group involved in designing a specification or standard of which software implementations are expected to be developed, with a primary focus on OASIS technical committees. The first step in achieving this is to establish a common and reusable model, metadata, methodology and representation for TAs.

Human experts in specific IT infrastructure and business domains possess substantial knowledge about prevention, remediation, and optimization of systems. However, there is a significant challenge in capturing, combining, and leveraging this siloed knowledge across domains.
 
SAF is a catalog-based XML collaborative knowledge framework that is designed to address these challenges by automating appropriate responses to changing business conditions and integrating contributions from diverse domains to provide competitive advantage. SAF has applicability in IT and business including cloud computing, service management, governance, security, energy, eGov, financial, emergency management, healthcare, and communications.
 
Cloud computing, in particular, exacerbates the separation between consumer-based business requirements and provider-supplied IT responses. SAF facilitates knowledge sharing across these domains, allowing consumer and provider to work cooperatively together to ensure adequate capacity, maximize quality of service, and reduce cost. The SAF technical committee considers cloud computing to be an area where the value of existing and developing standards could be significantly enhanced using SAF.
 
For more information on SAF, see the TC Charter, the FAQ, and the (working) Symptoms Automation Framework Documents.

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 OpenC2 TC was chartered to draft documents, specifications, lexicons or other artifacts to fulfill the needs of cyber security command and control in a standardized manner. The Technical Committee will leverage pre-existing standards to the greatest extent practical, identifying gaps pertaining to the command and control of technologies that provide or support cyber defenses. The TC will base its initial efforts on artifacts generated by the OpenC2 Forum, a community of cyber-security stakeholders that was facilitated by the National Security Agency; the Forum has published a language description document (RC4), actuator profiles, and open source prototype implementations.
 
For more information on the OpenC2 TC, see the TC Charter.
 
OpenC2 TC standing rules can be found under Additional Information.

The OASIS OData TC works to simplify the querying and sharing of data across disparate applications and multiple stakeholders for re-use in the enterprise, Cloud, and mobile devices. A REST-based protocol, OData builds on HTTP and JSON using URIs to address and access data feed resources. It enables information to be accessed from a variety of sources including (but not limited to) relational databases, file systems, content management systems, and traditional Web sites. OData provides a way to break down data silos and increase the shared value of data by creating an ecosystem in which data consumers can interoperate with data producers in a way that is far more powerful than currently possible, enabling more applications to make sense of a broader set of data. Every producer and consumer of data that participates in this ecosystem increases its overall value.

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