Applications of information technology

The mission of the Dataset Exchange WG is to: 1. Revise the Data Catalog Vocabulary, DCAT, taking account of related vocabularies and the extensive work done in developing a number of its application profiles. 2. Define and publish guidance on the use of application profiles when requesting and serving data on the Web.
 
DCAT is formulated as an RDF vocabulary and is expected to remain so, however, the working Group is agnostic about data formats. Methods for expressing DCAT in other (existing) formats are in scope.
 
Government data, scientific research data, industry/enterprise and cultural heritage data, whether shared openly or not, are all explicitly in scope.

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

The OASIS TOSCA TC works to enhance the portability of cloud applications and services across their entire lifecycle. TOSCA will enable the interoperable description of application and infrastructure cloud services, the relationships between parts of the service, and the operational behavior of these services (e.g., deploy, patch, shutdown)--independent of the supplier creating the service, and any particular cloud provider or hosting technology. TOSCA will also make it possible for higher-level operational behavior to be associated with cloud infrastructure management.
 
By increasing service and application portability in a vendor-neutral ecosystem, TOSCA will enable:

• Portable deployment to any compliant cloud
• Smoother migration of existing applications to the cloud
• Flexible bursting (consumer choice)
• Dynamic, multi-cloud provider applications

Cloud computing can become more valuable if the semi-automatic creation and management of application layer services can be ported across alternative cloud implementation environments so that the services remain interoperable. This core TOSCA specification provides a language to describe service components and their relationships using a service topology, and it provides for describing the management procedures that create or modify services using orchestration processes. The combination of topology and orchestration in a Service Template describes what is needed to be preserved across deployments in different environments to enable interoperable deployment of cloud services and their management throughout the complete lifecycle (e.g. scaling, patching, monitoring, etc.) when the applications are ported over alternative cloud environments.

The TOSCA Simple Profile in YAML specifies a rendering of TOSCA which aims to provide a more accessible syntax as well as a more concise and incremental expressiveness of the TOSCA DSL in order to minimize the learning curve and speed the adoption of the use of TOSCA to portably describe cloud applications.
 
This proposal describes a YAML rendering for TOSCA. YAML is a human friendly data serialization standard (http://yaml.org/) with a syntax much easier to read and edit than XML. As there are a number of DSLs encoded in YAML, a YAML encoding of the TOSCA DSL makes TOSCA more accessible by these communities.
 
This proposal prescribes an isomorphic rendering in YAML of a subset of the TOSCA v1.0 XML specification ensuring that TOSCA semantics are preserved and can be transformed from XML to YAML or from YAML to XML. Additionally, in order to streamline the expression of TOSCA semantics, the YAML rendering is sought to be more concise and compact through the use of the YAML syntax.

The Transformational Government TC advances an overall framework for using information technology to improve the delivery of public services. Unlike traditional e-Government strategies of the past, Transformational Government begins with citizen engagement to assure greater use and return on investment. The work of the TC includes defining the framework, identifying use cases, and providing adoption guidance for governments around the world, regardless of their history in implementing eGov.

Defining a common XML library of business documents (purchase orders, invoices, etc.).
 
The aims of the UBL TC shall be as follows:

1. To avert a crisis in electronic business caused by competing XML business-to-business document standards by choosing as a starting point an existing XML business document library as the basis for creating a new "Universal Business Language" that will be a synthesis of existing XML business document libraries.
2. To begin with xCBL 3.0 as the starting point and to develop the standard UBL library by mutually agreed-upon changes to xCBL 3.0 based on industry experience with other XML business libraries and with similar technologies such as Electronic Data Interchange.
3. To develop UBL in light of standards/specifications issued by UN/CEFACT, ISO, IEC, ITU, W3C, IETF, OASIS, and such other standards bodies and organizations as the UBL TC may deem relevant.
4. To harmonize UBL as far as practical with the ebXML specifications approved in Vienna (May 2001), with the work of the Joint Core Components initiative (a joint project of ANSI ASC X12 and the UN/EDIFACT Working Group), and with the work of other appropriate business information bodies.
5. To vest ownership of UBL in OASIS, a nonprofit corporation dedicated to the adoption of structured information standards, and to make it freely available to everyone without licensing or other fees.
6. Ultimately, to promote UBL to the status of an international standard for the conduct of XML-based electronic business.

VEL TC members are developing an interoperability standard that will enable the exchange of variability information among variant management tools and systems development tools. The goal is to enable the exchange of variability information among tools for variant management tools and systems development tools.
 
Variability is a widely used model for describing common and unique features of systems at all stages of the lifecycle. It describes the ability of artifacts to be used in different contexts by changing or customizing some characteristics of them, and those changeable characteristics are localized somewhere within the artifacts. VEL will eliminate the cost of building customized interfaces by defining a standard way for information to be exchanged among corresponding tools. Using VEL, a variant management tool will be able to read the variability from a development tool and pass configurations of selected system features to a development tool. By defining a common variability data interface that can be implemented by both the development tools and the variant management tools, VEL will enable a continuous development process for variable systems and more flexible use of tools.

The goal of the OASIS Virtual I/O Device (VIRTIO) TC is to simplify virtual devices, making them more extensible and more recognizable.
 
The purpose of VIRTIO is to ensure that virtual environments and guests have a straightforward, efficient, standard, and extensible mechanism for virtual devices, rather than boutique per-environment or per-OS mechanisms. PCI devices of the VIRTIO family as found in virtual environments are not all that different from physical PCI devices. Treating them similarly allows the guest to use standard PCI drivers and discovery mechanisms.
 
The TC intends to define formal specifications for virtual device buses (including PCI) for a variety of devices, including network devices. Specification development will be based upon the "Virtio PCI Card Specification" v0.9.5, seeking solutions that support portability, simplicity, least-surprise for driver authors, extensibility, and performance. The specification will also document existing implementations and practice.
 
The expected TC deliverables include:

• Specification of feature negotiation, configuration and queues, from both driver and device points of view
• Specification of device-specific configuration
• Non-normative code examples for operation of guest/host side of buffers
• Non-normative guide for creating devices which also support previous mode(s)

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.