OASIS Committee/Project Specification
XACML REST Profile Version 1.1
Defines a profile for the use of XACML in a RESTful architecture.
XACML REST Profile Version 1.1
Defines a profile for the use of XACML in a RESTful architecture.
Produced by:
OASIS eXtensible Access Control Markup Language (XACML) TCVoting history:
December 2018
OASIS Standard:
Cite as:
Cite as:
[xacml-rest-v1.1]
XACML REST Profile Version 1.1. Edited by Rémon Sinnema. 05 December 2018. OASIS Committee Specification 01.
https://docs.oasis-open.org/xacml/xacml-rest/v1.1/cs01/xacml-rest-v1.1-cs01.html.
Latest version: https://docs.oasis-open.org/xacml/xacml-rest/v1.1/xacml-rest-v1.1.html.
The DocBook Schema Version 5.0.1
Updated with the new Schematron rules so users can continue using DocBook 5.0 if they need to use newer Schematron tools.
The DocBook Schema Version 5.0.1
Updated with the new Schematron rules so users can continue using DocBook 5.0 if they need to use newer Schematron tools.
Produced by:
OASIS DocBook TCVoting history:
November 2018
OASIS Standard:
Committee Specification 01
Relax NG schemas
Schematron schema
DTD schema
XML schemas
XML catalog
DocBook NVDL file
Cite as:
Cite as:
[DocBook-v5.0.1]
The DocBook Schema Version 5.0.1. Edited by Robert Stayton. 07 November 2018. OASIS Committee Specification 01.
http://docs.oasis-open.org/docbook/docbook/v5.0.1/cs01/docbook-v5.0.1-cs01.html.
Latest version: http://docs.oasis-open.org/docbook/docbook/v5.0.1/docbook-v5.0.1.html.
OSLC Architecture Management Version 2.1
Defines the OSLC Architecture Management domain, a RESTful web services interface for the management of architectural resources and relationships between those and related resources such as product change requests, activities, tasks, requirements or test cases. To support these scenarios, this specification defines a set of HTTP-based RESTful interfaces in terms of HTTP methods: GET, POST, PUT and DELETE, as well as HTTP response codes, content type handling and resource formats.
OSLC Architecture Management Version 2.1
Defines the OSLC Architecture Management domain, a RESTful web services interface for the management of architectural resources and relationships between those and related resources such as product change requests, activities, tasks, requirements or test cases. To support these scenarios, this specification defines a set of HTTP-based RESTful interfaces in terms of HTTP methods: GET, POST, PUT and DELETE, as well as HTTP response codes, content type handling and resource formats.
Produced by:
OASIS OSLC Lifecycle Integration Domains TCVoting history:
October 2018
OASIS Standard:
Committee Specification 01
Cite as:
Cite as:
[OSLC-AM-2.1]
OSLC Architecture Management Specification 2.1. Part 1: Specification. Edited by Jim Amsden. 09 October 2018. OASIS Committee Specification 01.
http://docs.oasis-open.org/oslc-domains/oslc-am/v2.1/cs01/part1-architecture-management-spec/oslc-am-v2.1-cs01-part1-architecture-management-spec.html.
Latest version: http://docs.oasis-open.org/oslc-domains/oslc-am/v2.1/oslc-am-v2.1-part1-architecture-management-spec.html.
Cite as:
[OSLC-am-2.1-Part2]
OSLC Architecture Management Version 2.1. Part 2: Vocabulary. Edited by Jim Amsden. 09 October 2018. OASIS Committee Specification 01.
http://docs.oasis-open.org/oslc-domains/oslc-am/v2.1/cs01/part2-architecture-management-vocab/oslc-am-v2.1-cs01-part2-architecture-management-vocab.html.
Latest version: http://docs.oasis-open.org/oslc-domains/oslc-am/v2.1/oslc-am-v2.1-part2-architecture-management-vocab.html.
Emergency Data Exchange Language (EDXL) Tracking of Emergency Patients (TEP) Version 1.1
An XML messaging standard primarily for exchange of emergency patient and tracking information from the point of patient encounter through definitive care admission or field release. TEP supports patient tracking across the Emergency Medical Services (EMS) care continuum, as well as hospital evacuations and patient transfers, providing real-time information to responders, Emergency Management, coordinating organizations and care facilities in the chain of care and transport.
Emergency Data Exchange Language (EDXL) Tracking of Emergency Patients (TEP) Version 1.1
An XML messaging standard primarily for exchange of emergency patient and tracking information from the point of patient encounter through definitive care admission or field release. TEP supports patient tracking across the Emergency Medical Services (EMS) care continuum, as well as hospital evacuations and patient transfers, providing real-time information to responders, Emergency Management, coordinating organizations and care facilities in the chain of care and transport.
Produced by:
OASIS Emergency Management TCVoting history:
September 2018
OASIS Standard:
Cite as:
Cite as:
[EDXL-TEP-v1.1] Emergency Data Exchange Language (EDXL) Tracking of Emergency Patients (TEP) Version 1.1. Edited by Werner Joerg and Patti Iles Aymond. 21 September 2018. OASIS Committee Specification 02. http://docs.oasis-open.org/emergency/edxl-tep/v1.1/cs02/edxl-tep-v1.1-cs02.html. Latest version: http://docs.oasis-open.org/emergency/edxl-tep/v1.1/edxl-tep-v1.1.html.
Advanced Message Queuing Protocol (AMQP) Enforcing Connection Uniqueness Version 1.0
Enables two processes via AMQP v1.0 to enforce that only one open AMQP connection exists between the two of them.
Advanced Message Queuing Protocol (AMQP) Enforcing Connection Uniqueness Version 1.0
Enables two processes via AMQP v1.0 to enforce that only one open AMQP connection exists between the two of them.
Produced by:
OASIS Advanced Message Queuing Protocol (AMQP) TCVoting history:
September 2018
OASIS Standard:
Committee Specification 01
The work is covered by the RF on RAND Mode of the OASIS IPR Policy.
Cite as:
Cite as:
[soleconn-v1.0]
Advanced Message Queuing Protocol (AMQP) Enforcing Connection Uniqueness Version 1.0. Edited by Robert Godfrey. 17 September 2018. OASIS Committee Specification 01. http://docs.oasis-open.org/amqp/soleconn/v1.0/cs01/soleconn-v1.0-cs01.html. Latest version: http://docs.oasis-open.org/amqp/soleconn/v1.0/soleconn-v1.0.html.
Using the AMQP Anonymous Terminus for Message Routing Version 1.0
An open internet protocol for business messaging. AMQP defines links as a unidirectional transport for messages between a source and a target. The target of a link identifies the node to which messages are to be sent to. If a large number of distinct destinations are in use, or if the destinations to be sent to are not known ahead of time (for example, they are provided as a reply-to in incoming messages) then creating a link per destination can be burdensome. This document defines a mechanism whereby a single outgoing link can be used to transfer messages which are then routed using the address carried in their “to” field.
Using the AMQP Anonymous Terminus for Message Routing Version 1.0
An open internet protocol for business messaging. AMQP defines links as a unidirectional transport for messages between a source and a target. The target of a link identifies the node to which messages are to be sent to. If a large number of distinct destinations are in use, or if the destinations to be sent to are not known ahead of time (for example, they are provided as a reply-to in incoming messages) then creating a link per destination can be burdensome. This document defines a mechanism whereby a single outgoing link can be used to transfer messages which are then routed using the address carried in their “to” field.
Produced by:
OASIS Advanced Message Queuing Protocol (AMQP) TCVoting history:
September 2018
OASIS Standard:
Cite as:
Cite as:
[anonterm-v1.0]
Using the AMQP Anonymous Terminus for Message Routing Version 1.0. Edited by Robert Godfrey. 17 September 2018. OASIS Committee Specification 01. http://docs.oasis-open.org/amqp/anonterm/v1.0/cs01/anonterm-v1.0-cs01.html. Latest version: http://docs.oasis-open.org/amqp/anonterm/v1.0/anonterm-v1.0.html.
OSLC Change Management Version 3.0
Defines the OSLC Change Management domain, a RESTful web services interface for the management of product change requests, activities, tasks and relationships between those and related resources such as requirements, test cases, or architectural resources. To support these scenarios, this specification defines a set of HTTP-based RESTful interfaces in terms of HTTP methods: GET, POST, PUT and DELETE, HTTP response codes, content type handling and resource formats.
OSLC Change Management Version 3.0
Defines the OSLC Change Management domain, a RESTful web services interface for the management of product change requests, activities, tasks and relationships between those and related resources such as requirements, test cases, or architectural resources. To support these scenarios, this specification defines a set of HTTP-based RESTful interfaces in terms of HTTP methods: GET, POST, PUT and DELETE, HTTP response codes, content type handling and resource formats.
Produced by:
OASIS OSLC Lifecycle Integration Domains TCVoting history:
August 2018
OASIS Standard:
Committee Specification 02
Cite as:
Cite as:
[OSLC-CM-3.0-Part1]
OSLC Change Management Version 3.0. Part 1: Specification.
Edited by Jim Amsden. 24 August 2018. OASIS Committee Specification 02.
http://docs.oasis-open.org/oslc-domains/cm/v3.0/cs02/part1-change-mgt/cm-v3.0-cs02-part1-change-mgt.html.
Latest version: http://docs.oasis-open.org/oslc-domains/cm/v3.0/cm-v3.0-part1-change-mgt.html.
Cite as:
[OSLC-CM-3.0-Part2]
OSLC Change Management Version 3.0. Part 2: Vocabulary.
Edited by Jim Amsden, Samuel Padgett, and Steve Speicher.
24 August 2018. OASIS Committee Specification 02.
http://docs.oasis-open.org/oslc-domains/cm/v3.0/cs02/part2-change-mgt-vocab/cm-v3.0-cs02-part2-change-mgt-vocab.html.
Latest version: http://docs.oasis-open.org/oslc-domains/cm/v3.0/cm-v3.0-part2-change-mgt-vocab.html.
OSLC Requirements Management Version 2.1
Defines the OSLC Requirements Management domain. The specification supports key RESTful web service interfaces for the management of Requirements, Requirements Collections and supporting resources defined in the OSLC Core specification. To support these scenarios, this specification defines a set of HTTP-based RESTful interfaces in terms of HTTP methods: GET, POST, PUT and DELETE, HTTP response codes, content type handling and resource formats.
OSLC Requirements Management Version 2.1
Defines the OSLC Requirements Management domain. The specification supports key RESTful web service interfaces for the management of Requirements, Requirements Collections and supporting resources defined in the OSLC Core specification. To support these scenarios, this specification defines a set of HTTP-based RESTful interfaces in terms of HTTP methods: GET, POST, PUT and DELETE, HTTP response codes, content type handling and resource formats.
Produced by:
OASIS OSLC Lifecycle Integration Domains TCVoting history:
August 2018
OASIS Standard:
Committee Specification 01
Cite as:
Cite as:
[OSLC-RM-2.1-Part1]
OSLC Requirements Management Version 2.1. Part 1: Specification. Edited by Mark Schulte and Jad El-khoury. 24 August 2018. OASIS Committee Specification 01 http://docs.oasis-open.org/oslc-domains/oslc-rm/v2.1/cs01/part1-requirements-management-spec/oslc-rm-v2.1-cs01-part1-requirements-management-spec.html. Latest version: http://docs.oasis-open.org/oslc-domains/oslc-rm/v2.1/oslc-rm-v2.1-part1-requirements-management-spec.html.
Cite as:
[OSLC-RM-2.1-Part2]
OSLC Requirements Management Version 2.1. Part 2: Vocabulary. Edited by Mark Schulte and Jad El-khoury. 24 August 2018. OASIS Committee Specification 01 http://docs.oasis-open.org/oslc-domains/oslc-rm/v2.1/cs01/part2-requirements-management-vocab/oslc-rm-v2.1-cs01-part2-requirements-management-vocab.html. Latest version: http://docs.oasis-open.org/oslc-domains/oslc-rm/v2.1/oslc-rm-v2.1-part2-requirements-management-vocab.html.
TOSCA Simple Profile in YAML Version 1.2
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.
TOSCA Simple Profile in YAML Version 1.2
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.
Produced by:
OASIS Topology and Orchestration Specification for Cloud Applications (TOSCA) TCVoting history:
July 2018
OASIS Standard:
Cite as:
Cite as:
[TOSCA-Simple-Profile-YAML-v1.2]
TOSCA Simple Profile in YAML Version 1.2. Edited by Matt Rutkowski, Luc Boutier, and Chris Lauwers. 19 July 2018.
OASIS Committee Specification 01.
http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/cs01/TOSCA-Simple-Profile-YAML-v1.2-cs01.html.
Latest version: http://docs.oasis-open.org/tosca/TOSCA-Simple-Profile-YAML/v1.2/TOSCA-Simple-Profile-YAML-v1.2.html.
Classification of Everyday Living Version 1.0
Defines the Classification of Everyday Living (COEL) version 1.0 specification for the complete implementation of a compliant system. Examples and non-normative material are also offered as guidance.
Classification of Everyday Living Version 1.0
Defines the Classification of Everyday Living (COEL) version 1.0 specification for the complete implementation of a compliant system. Examples and non-normative material are also offered as guidance.
Produced by:
OASIS Classification of Everyday Living (COEL) TCVoting history:
June 2018
OASIS Standard:
Cite as:
Cite as:
[COEL-COEL-v1.0] Classification of Everyday Living Version 1.0.
Edited by Paul Bruton, Joss Langford, Matthew Reed, and David Snelling. 26 June 2018. OASIS Committee Specification 02.
http://docs.oasis-open.org/coel/COEL/v1.0/cs02/COEL-v1.0-cs02.html.
Latest version: http://docs.oasis-open.org/coel/COEL/v1.0/COEL-v1.0.html.
OSLC Change Management Version 3.0
Defines the OSLC Change Management domain, a RESTful web services interface for the management of product change requests, activities, tasks and relationships between those and related resources such as requirements, test cases, or architectural resources. To support these scenarios, this specification defines a set of HTTP-based RESTful interfaces in terms of HTTP methods: GET, POST, PUT and DELETE, HTTP response codes, content type handling and resource formats.
OSLC Change Management Version 3.0
Defines the OSLC Change Management domain, a RESTful web services interface for the management of product change requests, activities, tasks and relationships between those and related resources such as requirements, test cases, or architectural resources. To support these scenarios, this specification defines a set of HTTP-based RESTful interfaces in terms of HTTP methods: GET, POST, PUT and DELETE, HTTP response codes, content type handling and resource formats.
Produced by:
OASIS OSLC Lifecycle Integration Domains TCVoting history:
June 2018
OASIS Standard:
Committee Specification 01
Cite as:
Cite as:
[OSLC-CM-3.0-Part1]
OSLC Change Management Version 3.0. Part 1: Specification.
Edited by Jim Amsden. 08 June 2018. OASIS Committee Specification 01
http://docs.oasis-open.org/oslc-domains/cm/v3.0/cs01/part1-change-mgt/cm-v3.0-cs01-part1-change-mgt.html.
Latest version: http://docs.oasis-open.org/oslc-domains/cm/v3.0/cm-v3.0-part1-change-mgt.html.
Cite as:
[OSLC-CM-3.0-Part2]
OSLC Change Management Version 3.0. Part 2: Vocabulary.
Edited by Jim Amsden, Samuel Padgett, and Steve Speicher.
08 June 2018. OASIS Committee Specification 01.
http://docs.oasis-open.org/oslc-domains/cm/v3.0/cs01/part2-change-mgt-vocab/cm-v3.0-cs01-part2-change-mgt-vocab.html.
Latest version: http://docs.oasis-open.org/oslc-domains/cm/v3.0/cm-v3.0-part2-change-mgt-vocab.html.
Cloud Application Management for Platforms Version 1.2
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.
Cloud Application Management for Platforms Version 1.2
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.
Produced by:
OASIS Cloud Application Management for Platforms (CAMP) TCVoting history:
May 2018
OASIS Standard:
Cite as:
Cite as:
[CAMP-v1.2] Cloud Application Management for Platforms Version 1.2. Edited by Jacques Durand, Adrian Otto, Gilbert Pilz, and Tom Rutt.
15 May 2018. OASIS Committee Specification 01. http://docs.oasis-open.org/camp/camp-spec/v1.2/cs01/camp-spec-v1.2-cs01.html.
Latest version: http://docs.oasis-open.org/camp/camp-spec/v1.2/camp-spec-v1.2.html.
No results with the selected filters