IT in general

Available (1690)

Showing 1465 - 1476 per page



Cloud Storage TWG

The Cloud Storage TWG acts as the primary technical entity for the SNIA to identify, develop, and coordinate systems standards for Cloud Storage. This group aims to produce a comprehensive set of specifications and drives consistency of interface standards and messages across the various Cloud Storage related efforts. The TWG also documents system-level requirements and shares these with other Cloud Storage standards organizations under the guidance of the SNIA Technical Council and in cooperation with the SNIA Strategic Alliances Committee.

CSTWG

Storage Management Initiative

The Storage Management Initiative Technical Work Group (SMI TWG) is responsible for the maintenance and evolution of the SNIA Storage Management Initiative Specification (SMI-S). SMI-S defines an interface for the interoperable management of a heterogeneous Storage Area Network (SAN). It describes the information available to a WBEM Client from an SMI-S compliant CIM Server via an object-oriented, XML-based, messaging-based interface designed to support the specific requirements of managing devices in and through SANs.

SMI TWG

Solid State Storage Initiative

The Solid State Storage Technical Work Group has been created for the purpose of developing standards related to system implementations of Solid State Storage technology.
The Solid State Storage TWG:

  • Acts as the primary technical entity for the SNIA to identify, develop, and coordinate systems standards for Solid State Storage.
  • Produces a comprehensive set of specifications and drives consistency of interface standards and messages across the various Solid State Storage related efforts.
  • Documents system-level requirements and shares these with other Solid State Storage standards organizations under the guidance of the SNIA Technical Council and in cooperation with the SNIA Strategic Alliances Committee.
SSSI

Solid State Storage System

The Solid State Storage System (S4) TWG was created for the purpose of addressing the unique performance behavior of solid state storage systems. The TWG creates specifications which provide guidance to accurately measure the performance of enterprise arrays as oppose to devices. These specifications are vendor agnostic and support all the solid state storage system technologies of member companies.

The S4 TWG:

  • Acts as the primary technical entity for the SNIA to identify, develop, and coordinate system performance standards for solid state storage systems
  • Produces a comprehensive set of specifications and drives consistency of measurement guidelines and messages related to solid state storage systems
  • Documents system–level requirements and shares these with other performance standards organizations under the guidance of the SNIA Technical Council and in cooperation with the SNIA Strategic Alliances Committee
S4

Accessible Rich Internet Applications (ARIA) Working Group

The mission of the Accessible Rich Internet Applications Working Group (ARIA WG, formerly part of the Protocols and Formats Working Group) is to develop technologies that enhance accessibility of web content for people with disabilities. This includes continued development of the Accessible Rich Internet Applications (WAI-ARIA) suite of technologies and other technical specifications when needed to bridge known gaps.
 
The scope of the working group is

  • Continue development of existing ARIA specifications to address needs reported by authors and to achieve parity with native host languages, creating new ARIA specifications where necessary;
  • For each ARIA specification developed by this Working Group, create a corresponding Accessibility API Mappings specification defining the correct exposure for each platform;
  • For all attributes defined by this Working Group, document best practices for authors;
  • Collaborate with other groups to create mapping specifications for native host language semantics;
  • Develop testing tools which can be used to verify accessibility implementations by examining the mappings exposed via platform accessibility APIs;
  • Collaborate with other groups involved in defining ARIA techniques and implementing ARIA support.

Accessible Platform Architectures (APA) Working Group

The mission of the Accessible Platform Architectures Working Group (APA WG) is to ensure W3C specifications provide support for accessibility to people with disabilities. The group advances this mission through review of W3C specifications, development of technical support materials, collaboration with other Working Groups, and coordination of harmonized accessibility strategies within W3C.
 
The scope of the working group is

  • Support W3C Working Groups and external organizations collaborating on web technologies to create technical specifications that provide features needed for accessibility to people with disabilities:
    • Provide expertise to the W3C about the needs of users with disabilities, including both serving as a resource base and providing educational in-reach to the W3C community as needed;
    • Review W3C requirements and specifications (accessibility horizontal reviews, AHR) as needed to identify accessibility issues and make recommendations to the appropriate Working Group, particularly at the First Public Working Draft and Last Call or Candidate Recommendation stages and when explicit milestone review readiness is signaled;
    • Work closely with Working Groups when needed to help them architect their specifications to support, and not unknowingly interfere with, accessibility;
  • Develop and publish explanatory information about accessibility of web technology:
    • Document concrete guidance about how to ensure technical specifications appropriately support accessibility;
    • Collect information about technology features, implementation, and usage patterns to institutionalize W3C knowledge about present-day accessibility problems, including for emerging technologies such as social networking, real-time communications, Web-based television viewing, etc.;
  • Explore new technologies and accessibility challenges and begin to develop remediation approaches:
    • Leverage existing W3C markup technologies to produce new specifications or additions to existing specifications which support content personalization for various identified accessibility requirements;
    • Determine accessibility considerations for new devices and technologies, such as artificial intelligence, authentication, automotive interfaces, digital publications, graphics and media, mobile communications devices, payments, tablets, virtual and augmented and mixed reality, Web-enabled television, Web of Things, etc.;
    • Identify gaps and questions from accessibility specification reviews that may need research, and articulate findings and specific questions for discussion in various additional fora;
  • Coordinate with other accessibility stakeholders (including other WAI groups, accessibility proponents in other groups, and external accessibility organizations) to develop harmonized accessibility guidance across W3C:
    • Coordinate with accessibility proponents in W3C technical groups to help ensure accessibility solutions are developed in a consistent manner across technologies and to ensure that accessibility needs are addressed at an appropriate part of the technology stack;
    • Involve accessibility proponents in other fora - such as the WAI Interest Group, community groups, coordination activities, and other centers of expertise - to maximize the knowledge and impact brought to the group's activities;
    • Advocate creation and reuse of common implementations of functions that are required by accessibility;
    • Review non-W3C technologies that impact the accessibility of W3C technologies;
    • Strategize solutions within W3C and via liaisons with external organizations.

Accessible Rich Internet Applications Working Group

The mission of the Accessible Rich Internet Applications Working Group is to enhance the accessibility of web content through the development of supplemental attributes, including roles, states, and other properties, that can be applied to native host language elements and exposed via platform accessibility APIs.
 
The scope of the working group is

  • Continue development of existing ARIA specifications to address needs reported by authors and to achieve parity with native host languages, creating new ARIA specifications where necessary;
  • For each ARIA specification developed by this Working Group, create a corresponding Accessibility API Mappings specification defining the correct exposure for each platform;
  • For all attributes defined by this Working Group, document best practices for authors;
  • Collaborate with other groups to create mapping specifications for native host language semantics;
  • Develop testing tools which can be used to verify accessibility implementations by examining the mappings exposed via platform accessibility APIs;
  • Collaborate with other groups involved in defining ARIA techniques and implementing ARIA support.

OASIS Symptoms Automation Framework (SAF) TC

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.

Solid State Storage (SSS) Performance Test Specification (PTS)

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.

SSSPTSv2.0.1

NVM Programming Model

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.

NPM v1.2

Linear Tape File System (LTFS) Format Specification

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.
LTFS v2.5