OASIS

The SAML V2.0 metadata specification [SAML2Meta] defines an XML schema and a set of basic processing rules intended to facilitate the implementation and deployment of SAML profiles, and generallyany profile or specification involving SAML. Practical experience has shown that the most complex aspects of implementing most SAML profiles, and obtaining interoperability between such implementations, are in the areas of provisioning federated relationships between deployments, and establishing the validity of cryptographic signatures and handshakes. Because the metadata specification was largely intended to solve those exact problems, additional profiling is needed to improve and clarify the use of metadata in addressing those aspects of deployment. The purpose of this profile is to guarantee that in a correct implementation, all security considerations not deriving from the particular cryptography used (i.e., algorithm strength, key sizes) can be isolated to metadata exchange and acceptance, and not affect the runtime processing of messages.

The TOSCA Simple Profile in YAML specifies a rendering of TOSCA which aims to provide a more accessible syntax aswell 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.

This specification defines a profile for the use of the OASIS eXtensible Access Control Markup Language (XACML), versions 3.0 [XACMLv3]and earlier. Use of this profile requires no changes or extensions to the XACMLstandard. This specification assumes the reader is somewhat familiar with XACML. XACML can be used for controlling access within a single application.This removes hard-coded security constraints from the application code, making it easier to change them. It also makes it possible to use a standard Policy Decision Point (PDP), so that organizations can make a proper make-or-buy decision. For virtually all organizations, authorization is not their core business, so being able to use an off-the-shelf product is appealing. Although these are substantial benefits, XACML really shines when authorizationis completely externalized from the application. Policies can then be reused across many applications, each using the same PDP. This leads to greater consistency of access control rules and improved efficiency in maintaining them.

This standard describes the specifications of the “virtio” family of devices. These devices are found in virtual environments, yet by design they look like physical devices to the guest within the virtual machine. This similarity allows the guest to use standard drivers and discovery mechanisms.The purpose of virtio and this specification is that virtual environments and guests should have a straightfor-ward, efficient, standard and extensible mechanism for virtual devices, rather than boutique per-environmentor per-OS mechanisms.

This document defines the artifacts and APIs that need to be offered by a Platform as a Service (PaaS) cloud to manage the building, running, administration, monitoring and patching of applications in the cloud. Its purpose is to enable interoperability among self-service interfaces to PaaS clouds by defining artifacts and formats that can be used with any conforming cloud and enable independent vendors to create tools and services that interact with any conforming cloud using the defined interfaces. Cloud vendors can use these interfaces to develop new PaaS offerings that will interact with independently developed tools and components.
 
This document defines the artifacts and APIs that need to be offered by a Platform as a Service (PaaS) cloud to manage the building, running, administration, monitoring and patching of applications in the cloud. Its purpose is to enable interoperability among self-service interfaces to PaaS clouds by defining artifacts and formats that can be used with any conforming cloud and enable independent vendors to create tools and services that interact with any conforming cloud using the defined interfaces. Cloud vendors can use these interfaces to develop new PaaS offerings that will interact with independently developed tools and components.
 
The following is a non-exhaustive list of the use cases which are supported by this specification.

• Building and packaging an application in a local Application Development Environment (ADE)
• Building an application in an ADE running in the cloud
• Importing a Platform Deployment Package into the cloud
• Uploading application artifacts into the cloud
• Run, stop, suspend, snapshot, and patch an application

This document defines a simplified profile of the TOSCA version 1.0 specification in a YAML rendering which is intended to simplify the authoring of TOSCA service templates. This profile defines a less verbose and more human-readable YAML rendering, reduced level of indirection between different modeling artifacts as well as the assumption of a base type system.
 
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.

This document defines a simplified profile of the TOSCA version 1.0 specification in a YAML rendering which is intended to simplify the authoring of TOSCA service templates. This profile defines a less verbose and more human-readable YAML rendering, reduced level of indirection between different modeling artifacts as well as the assumption of a base type system.
 
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.

This document defines the artifacts and APIs that need to be offered by a Platform as a Service (PaaS) cloud to manage the building, running, administration, monitoring and patching of applications in the cloud. Its purpose is to enable interoperability among self-service interfaces to PaaS clouds by defining artifacts and formats that can be used with any conforming cloud and enable independent vendors to create tools and services that interact with any conforming cloud using the defined interfaces. Cloud vendors can use these interfaces to develop new PaaS offerings that will interact with independently developed tools and components.
 
This document defines the artifacts and APIs that need to be offered by a Platform as a Service (PaaS) cloud to manage the building, running, administration, monitoring and patching of applications in the cloud. Its purpose is to enable interoperability among self-service interfaces to PaaS clouds by defining artifacts and formats that can be used with any conforming cloud and enable independent vendors to create tools and services that interact with any conforming cloud using the defined interfaces. Cloud vendors can use these interfaces to develop new PaaS offerings that will interact with independently developed tools and components.
 
The following is a non-exhaustive list of the use cases which are supported by this specification.

• Building and packaging an application in a local Application Development Environment (ADE)
• Building an application in an ADE running in the cloud
• Importing a Platform Deployment Package into the cloud
• Uploading application artifacts into the cloud
• Run, stop, suspend, snapshot, and patch an application

While industry-specific data formats have the advantage of maximal optimization for their busines scontext, the existence of different formats to accomplish the same purpose in different business domainsis attended by a number of significant disadvantages as well.  The OASIS Universal Business Language (UBL) is intended to help solve these problems by defininga generic XML interchange format for business documents that can be restricted or extended to meet the requirements of particular industries.

The Darwin Information Typing Architecture (DITA) is an XML-based architecture for authoring, producing, anddelivering topic-oriented, information-typed content that can be reused and single-sourced in a variety of ways.While DITA historically has been driven by the requirements of large-scale technical documentation authoring,management, and delivery, it is a standard that is applicable to any kind of publication or information that mightbe presented to readers, including interactive training and educational materials, standards, reports, businessdocuments, trade books, travel and nature guides, and more.DITA is designed for creating new document types and describing new information domains based on existingtypes and domains. The process for creating new types and domains is called specialization. Specializationenables the creation of specific, targeted XML grammars that can still use tools and design rules that weredeveloped for more general types and domains; this is similar to how classes in an object-oriented system caninherit the methods of ancestor classes.

The OASIS CAMP TC advances an interoperable protocol that cloud implementers can use to package and deploy their applications. CAMP defines interfaces for self-service provisioning, monitoring, and control. Based on REST, CAMP is expected to foster an ecosystem of common tools, plugins, libraries and frameworks, which will allow vendors to offer greater value-add.
 
Common CAMP use cases include:

• moving on-premise applications to the cloud (private or public)
• redeploying applications across cloud platforms from multiple vendors

For more information on CAMP, see the TC Charter.

The OASIS AMQP TC advances a vendor-neutral and platform-agnostic protocol that offers organizations an easier, more secure approach to passing real-time data streams and business transactions. The goal of AMQP is to ensure information is safely and efficiently transported between applications, among organizations, across distributed cloud computing environments, and within mobile infrastructures. AMQP avoids proprietary technologies, offering the potential to lower the cost of enterprise middleware software integrations through open interoperability. By enabling a commoditized, multi-vendor ecosystem, AMQP seeks to create opportunities for transforming the way business is done in the Cloud and over the Internet.