Standard

The LTFS Format Specification defines a file system format separate from any implementation on data storage media. Using this format, data is stored in LTFS Volumes. An LTFS Volume holds data files and corresponding metadata to completely describe the directory and file structures stored on the volume.
The LTFS Format has these features:
An LTFS Volume can be mounted and volume content accessed with full use of the data without the need to access other information sources.

• Data can be passed between sites and applications using only the information written to an LTFS Volume.
• Files can be written to, and read from, an LTFS Volume using standard POSIX file operations.

The LTFS Format is particularly suited to these usages:

• Data export and import.
• Data interchange and exchange.
• Direct file and partial file recall from sequential access media.
• Archival storage of files using a simplified, self-contained or “self-describing” format on sequential access media.

The IP Drive Management Specification describes the management features and functions of a storage device class known as IP Based Drives. It includes a taxonomy covering the scope of involved device capabilities.

The NVM Programming Model was developed to address the ongoing proliferation of new non-volatile memory (NVM) functionality and new NVM technologies. An extensible NVM Programming Model is necessary to enable an industry wide community of NVM producers and consumers to move forward together through a number of significant storage and memory system architecture changes.

This specification defines recommended behavior between various user space and operating system (OS) kernel components supporting NVM. This specification does not describe a specific API. Instead, the intent is to enable common NVM behavior to be exposed by multiple operating system specific interfaces.

After establishing context, the specification describes several operational modes of NVM access. Each mode is described in terms of use cases, actions and attributes that inform user and kernel space components of functionality that is provided by a given compliant implementation.

The SNIA has developed methods which enable manufacturers to set, and customers to compare, the performance specifications of Solid State Storage devices, which are evolving with the state of the technology. These specifications define a set of device level tests and methodologies which enable comparative testing of SSS devices for Enterprise and Client systems.

The Swordfish Scalable Storage Management API ("Swordfish") uses RESTful interface semantics and a standardized data model to provide a scalable, customer-centric interface for managing storage and related data services.

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 current practice of the exchange of business documents by means of telecommunications – 65 usually defined as e-Business presents a major opportunity to improve the competitiveness of 66 companies, especially for Small and Medium Enterprises (SME).

The purpose of this document is to define globally consistent invoicing processes for the worldwide supply chains, using the UN/CEFACT Modelling Methodology (UMM) approach and Unified Modelling Language to describe and detail the business processes and transactions involved.

This BRS details the requirements for the Scheduling processes. The scheduling process supports various demand and supply modes, such as Kanban, Synchronized, MRP or VMI (CPFR).

Specification that describes the business process and requirements for the invoicing process. The invoicing process is used to exchange the invoice between the supplier and the for the supply of goods or services ordered, delivered, received, consumed, etc. This document describes the variants of invoicing in use in trade and industry. It considers the legal statements and, to a certain extent, the corrections of a previously sent invoice, by using credit notes or debit notes.

This section describes the extent and limits of the business processes within the supply chain being described in this document. Each industry may specify, based on the BRS of the cross industry catalogue processes, its industry specific use of the catalogue message and the business processes. It also allows for industry specific functionality on details to describe a specific product. Name/Value pairs in the catalogue documents allows the Catalogue Provider to add attributes to further specify their products in the existing structure. If further elaboration is needed an industryspecific ontology can be made. Industry specific ontology is outside the scope of this BRS