This specification defines schema for two XML document types: Package Descriptors and Deployment Descriptors. Package Descriptors define characteristics of a package used to deploy a solution. Deployment Descriptors define characteristics of the content of a solution package, including the requirements that are relevant for creation, configuration and maintenance of the solution content. The semantics of the descriptors are fully defined, allowing software implementations to precisely understand the intent of the descriptor authors and to use the information provided in the descriptors to support solution deployment.

Status:

This document was last revised or approved by the OASIS Solution Deployment Descriptor (SDD) Technical Committee on the above date. The level of approval is also listed above. Check the “Latest Version” or “Latest Approved Version” location noted above for possible later revisions of this document.

Technical Committee members should send comments on this specification to the Technical Committee’s email list. Others should send comments to the Technical Committee by using the “Send A Comment” button on the Technical Committee’s web page at http://www.oasis-open.org/committees/sdd/.

For information on whether any patents have been disclosed that may be essential to implementing this specification, and any offers of patent licensing terms, please refer to the Intellectual Property Rights section of the Technical Committee web page (http://www.oasis-open.org/committees/sdd/ipr.php.

The non-normative errata page for this specification is located at http://www.oasis-open.org/committees/sdd/.

Notices

All capitalized terms in the following text have the meanings assigned to them in the OASIS Intellectual Property Rights Policy (the "OASIS IPR Policy"). The full Policy may be found at the OASIS website.

This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published, and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this section are included on all such copies and derivative works. However, this document itself may not be modified in any way, including by removing the copyright notice or references to OASIS, except as needed for the purpose of developing any document or deliverable produced by an OASIS Technical Committee (in which case the rules applicable to copyrights, as set forth in the OASIS IPR Policy, must be followed) or as required to translate it into languages other than English.

The limited permissions granted above are perpetual and will not be revoked by OASIS or its successors or assigns.

This document and the information contained herein is provided on an "AS IS" basis and OASIS DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY OWNERSHIP RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

OASIS requests that any OASIS Party or any other party that believes it has patent claims that would necessarily be infringed by implementations of this OASIS Committee Specification or OASIS Standard, to notify OASIS TC Administrator and provide an indication of its willingness to grant patent licenses to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification.

OASIS invites any party to contact the OASIS TC Administrator if it is aware of a claim of ownership of any patent claims that would necessarily be infringed by implementations of this specification by a patent holder that is not willing to provide a license to such patent claims in a manner consistent with the IPR Mode of the OASIS Technical Committee that produced this specification. OASIS may include such claims on its website, but disclaims any obligation to do so.

OASIS takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on OASIS' procedures with respect to rights in any document or deliverable produced by an OASIS Technical Committee can be found on the OASIS website. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this OASIS Committee Specification or OASIS Standard, can be obtained from the OASIS TC Administrator. OASIS makes no representation that any information or list of intellectual property rights will at any time be complete, or that any claims in such list are, in fact, Essential Claims.

The name "OASIS", is a trademark of OASIS, the owner and developer of this specification, and should be used only to refer to the organization and its official outputs. OASIS welcomes reference to, and implementation and use of, specifications, while reserving the right to enforce its marks against misleading uses. Please see http://www.oasis-open.org/who/trademark.php for above guidance.

1.5 How to Read this Document 10

1.6 Motivation. 10

1.7 Requirements. 11

1.8 XML Namespaces. 13

1.9 Notational Conventions. 13

1.10 General Document Conventions. 13

1.11 Diagram Conventions. 13

1.12 Normative References. 15

1.13 Non-Normative References. 15

2 Solution Deployment Descriptor Overview. 16

2.1 Package and Deployment Descriptors. 16

2.2 Topology. 16

2.3 Content and Artifacts. 16

2.4 Resulting and Changed Resources. 17

2.5 Base, Selectable and Localization Content Hierarchies. 17

3 Package Descriptor 19

3.1 PackageDescriptor 19

3.1.1 PackageDescriptor Property Summary. 19

3.1.2 PackageDescriptor Property Usage Notes. 19

3.2 DescriptorInfoGroup. 20

3.2.1 DescriptorInfoGroup Property Usage Notes. 20

3.3 PackageIdentityType. 22

3.3.1 PackageIdentityType Property Summary. 22

3.3.2 PackageIdentityType Property Usage Notes. 22

3.4 IdentityType. 24

3.4.1 IdentityType Property Summary. 24

3.4.2 IdentityType Property Usage Notes. 25

3.5 MaintenanceInformationType. 26

3.5.1 MaintenanceInformationType Property Summary. 26

3.5.2 MaintenanceInformationType Property Usage Notes. 26

3.6 FixIdentityType. 27

3.6.1 FixIdentityType Property Summary. 27

3.6.2 FixIdentityType Property Usage Notes. 27

3.7 BuildInformationType. 27

3.7.1 BuildInformationType Property Summary. 28

3.7.2 BuildInformationType Property Usage Notes. 28

3.8 ManufacturerType. 28

3.8.1 ManufacturerType Property Summary. 28

3.8.2 ManufacturerType Property Usage Notes. 28

3.9 LocationType. 29

3.9.1 LocationType Property Summary. 29

3.9.2 LocationType Property Usage Notes. 29

3.10 VersionType. 29

3.11 ContentsType. 29

3.11.1 ContentsType Property Summary. 29

3.11.2 ContentsType Property Usage Notes. 30

3.12 ContentType. 30

3.12.1 ContentType Property Summary. 30

3.12.2 ContentType Property Usage Notes. 30

3.13 DigestInfoGroup. 31

3.13.1 DigestInfoGroup Property Usage Notes. 31

4 Deployment Descriptor 32

4.1 DeploymentDescriptor 32

4.1.1 DeploymentDescriptor Property Summary. 33

4.1.2 DeploymentDescriptor Property Usage Notes. 33

4.2 Topology. 34

4.2.1 TopologyType. 35

4.2.2 ResourceType. 36

4.2.3 PropertyType. 39

4.2.4 ResultingPropertyType. 39

4.3 Atomic Content Elements. 40

4.3.1 InstallableUnitType. 41

4.3.2 ConfigurationUnitType. 44

4.3.3 ArtifactType. 46

4.3.4 InstallationArtifactsType. 49

4.3.5 ConfigurationArtifactsType. 50

4.3.6 OperationListType. 50

4.3.7 OperationType. 50

4.3.8 ArgumentListType. 51

4.3.9 ArgumentType. 51

4.3.10 OutputVariableListType. 52

4.3.11 OutputVariableType. 53

4.3.12 AdditionalContentType. 53

4.3.13 SubstitutionType. 54

4.3.14 CompletionType. 55

4.4 Constraints. 56

4.4.1 CapacityConstraintType. 57

4.4.2 CapacityValueType. 58

4.4.3 ConsumptionConstraintType. 59

4.4.4 ConsumptionConstraintValueType. 60

4.4.5 PropertyConstraintType. 61

4.4.6 PropertyValueListType. 61

4.4.7 VersionConstraintType. 62

4.4.8 VersionConstraintValueType. 63

4.4.9 VersionValueType. 63

4.4.10 VersionRangeType. 64

4.4.11 MaxVersionType. 65

4.4.12 UniquenessConstraintType. 65

4.4.13 RelationshipConstraintType. 66

4.5 Conditions. 67

4.5.1 ConditionType. 67

4.5.2 AlternativeConditionalType. 69

4.5.3 ConditionalResourceConstraintType. 70

4.5.4 ConditionalPropertyConstraintType. 72

4.6 Variables. 73

4.6.1 VariableExpressionType. 73

4.6.2 BaseVariableType. 74

4.6.3 VariablesType. 75

4.6.4 ParametersType. 76

4.6.5 BaseParameterType. 77

4.6.6 IntegerParameterType. 78

4.6.7 BoundaryType. 79

4.6.8 StringParameterType. 80

4.6.9 StringCaseType. 81

4.6.10 BooleanParameterType. 81

4.6.11 URIParameterType. 81

4.6.12 ResourcePropertyType. 82

4.6.13 DerivedVariableType. 83

4.6.14 ConditionalDerivedVariableExpressionType. 83

4.7 Requirements. 84

4.7.1 RequirementsType. 84

4.7.2 RequirementType. 85

4.7.3 AlternativeRequirementType. 87

4.7.4 ResourceConstraintGroup. 88

4.7.5 RequirementResourceConstraintType. 90

4.7.6 InternalDependencyType. 91

4.7.7 DependencyType. 92

4.7.8 RequiredBaseType. 93

4.7.9 RequiredBaseConstraintType. 94

4.7.10 AlternativeRequiredBaseConstraintType. 96

4.8 Resulting and Changed Resources. 97

4.8.1 ResultingResourceType. 97

4.8.2 ResultingChangeType. 99

4.8.3 RelationshipType. 101

4.9 Composite Content Elements. 101

4.9.1 CompositeInstallableType. 103

4.9.2 CompositeUnitType. 106

4.10 Aggregation. 108

4.10.1 ReferencedPackageType. 112

4.10.2 ResourceMapType. 115

4.10.3 ResultingResourceMapType. 116

4.10.4 ResultingChangeMapType. 118

4.10.5 RequisitesType. 119

4.11 Base Content 120

4.11.1 BaseContentType. 120

4.12 Content Selectability. 121

4.12.1 SelectableContentType. 121

4.12.2 GroupsType. 122

4.12.3 GroupType. 123

4.12.4 FeaturesType. 124

4.12.5 FeatureType. 125

4.12.6 NestedFeatureType. 126

4.12.7 MultiplicityType. 129

4.12.8 FeatureReferenceType. 130

4.12.9 ContentElementReferenceType. 130

4.12.10 PackageFeatureReferenceType. 131

4.12.11 ConstrainedResourceType. 131

4.12.12 MultiplicityConstraintType. 132

4.12.13 RequiredContentSelectionType. 132

4.12.14 ContentSelectionFeatureType. 133

4.12.15 MultiSelectType. 134

4.13 Localization. 134

4.13.1 LocalizationContentType. 135

4.13.2 LocalizationUnitType. 136

4.13.3 CompositeLocalizationUnitType. 139

4.13.4 LanguageSelectionsType. 142

4.13.5 OptionalLanguagesType. 142

4.13.6 LanguagesType. 143

4.13.7 LanguageType. 143

4.13.8 LanguageSetType. 144

4.14 Display Information. 145

4.14.1 DescriptionGroup. 145

4.14.2 DisplayElementGroup. 145

4.14.3 DisplayTextType. 146

5 Conformance. 147

5.1 General Conformance Statements. 147

5.2 Conformance Levels. 147

5.2.1 CL Capabilities. 147

5.2.2 Conformance Level Differences. 148

5.3 Profiles. 150

5.3.1 Profile Creation. 150

5.3.2 Profile Publication. 150

5.3.3 Profile Applicability. 151

5.4 Compatibility Statements. 151

5.5 Conformance Clause. 151

5.5.1 Conformance for Users of This Specification. 151

5.5.2 Conformance for This Specification Itself 151

A. Schema File List 153

B. Acknowledgements. 154

1 Introduction

The Solution Deployment Descriptor (SDD) specification defines a standard, in the form of a schema for XML documents, called Solution Deployment Descriptors, or SDDs. SDDs define metadata that describes the packaging and deployment characteristics of resources that are relevant for their lifecycle management, including creation, configuration and maintenance.

A.1 Terminology

The following terms are used in this specification in a specialized sense that might differ from definitions elsewhere.

Artifact

Zero or more files and/or metadata used to perform a deployment lifecycle operation on a resource.

Deployment lifecycle

The stages marking maturation of a solution: develop, package, integrate, manufacture, install, configure, evaluate, deploy into production, upgrade and/or update, uninstall.

Host Resource

A resource that provides the execution environment for another resource.

Package

A set of artifacts used to perform deployment lifecycle operations on a group of related resources that make up a solution.

Resource

A particular element of a computing environment, such as a computer system, an operating system, a Web server, a software application, or a complex solution.

Solution

One or more interrelated resources on which deployment lifecycle operations can be performed.

Target Resource

A resource that processes artifacts to perform deployment lifecycle operations on another resource. The host resource often serves as the target resource.

Topology

The physical or logical layout of a solution’s resources.

Update (n.)

A package that replaces a limited set of the resources in a solution instance. An update does not require migration.

Upgrade (n.)

A package that replaces all, or a significant portion of, the resources used in a solution. An upgrade might or might not require migration.

1.1 Purpose

The purpose of this document is to provide the normative specification of the SDD, including concepts, structure, syntax, semantics and usage.

1.2 Scope

This document is the specification for the SDD. It consists of both normative and non-normative prose, diagrams, schema and examples. The document is intended to facilitate an understanding of the SDD concepts, structure, syntax, semantics and usage. This document is not intended to be a tutorial.

This document is the full SDD specification, but it also is augmented with other documents produced by the SDD TC, including the SDD XML Schema and Examples (see Appendix [A]), [SDDP], [SDDSP] and the set of SDD profiles (see section [5.3]), as well as documents produced by others (see section [5.3.1]).

1.3 Audience

This document is intended to assist those who require an understanding of the nature and details of the SDD. This includes architects, developers, solution integrators and service/support personnel who generate, consume, or otherwise use SDDs, as well as those who develop tooling and applications for constructing and deploying SDDs.

1.4 How to Read this Document

The various audiences of this specification might have different objectives and purposes when reading the document. You might wish to generally understand the SDD, or learn the details of the SDD to create or consume SDDs, or use the document as a reference.

§ If your purpose is to understand the major capabilities and characteristics of the SDD and how they fit together, start by reading the Introductions to the major sections: [3], [4] and [4.1]–[4.14].

§ If your purpose is to understand the major elements of the SDD and how they work together to accomplish the goals of this specification, read in addition to the above, the introductions to each of the type sections [3.1]–[3.13] and the type subsections within sections [4.2]–[4.14].

§ If your purpose is to understand the syntax of the SDD, look at the tables in each of the Property Summary sections.

§ If your purpose is to understand the semantics of the elements and attributes of the SDD, read the Property Usage Notes sections.

§ If your purpose is to understand only the package descriptor, subset the above suggestions to focus on the sub-sections within section [3].

§ If your purpose is to understand only the deployment descriptor, subset the above suggestions to focus on the sub-sections within section [4].

1.5 Motivation

The motivation for producing this specification is best expressed in this excerpt from the SDD Technical Committee’s charter:

Deployment and lifecycle management of a set of interrelated software, hereinafter referred to as a solution, is a predominantly manual operation because there is currently no standardized way to express installation packaging for a multi-platform environment. Each hosting platform or operating system has its own format for expressing packaging of a single installable unit but, even on these homogeneous platforms, there is no standardized way to combine packages into a single aggregated unit without significant re-creation of the dependency and installation instructions. The problem is compounded when the solution is to be deployed across multiple, heterogeneous, platforms. A standard for describing the packaging and mechanism to express dependencies and various lifecycle management operations within the package would alleviate these problems and subsequently enable automation of these highly manual and error-prone tasks.

The purpose of this Technical Committee is to define XML schema to describe the characteristics of an installable unit (IU) of software that are relevant for core aspects of its deployment, configuration and maintenance. This document will be referred to as the Solution Deployment Descriptor (SDD).

SDDs will benefit member companies and the industry in general by providing a consistent model and semantics to address the needs of all aspects of the IT industry dealing with software deployment, configuration and lifecycle management. The benefits of this work include:

· ability to describe software solution packages for both single and multi-platform heterogeneous environments.

· ability to describe software solution packages independent of the software installation technology or supplier.

· ability to provide information necessary to permit full lifecycle maintenance of software solutions.

1.6 Requirements

A summary of requirements satisfied by this SDD specification follows. Detailed requirements that support approved use cases are available at the SDD TC Web page, http://www.oasis-open.org/committees/sdd.

Solution lifecycle management

The SDD must provide information to support the complete lifecycle of a software solution. Certain key requirements are applicable to all phases of deployment lifecycle operation: planning, installation, configuration, maintenance, upgrade, migration and uninstallation.

Solution requirements for environment to perform lifecycle management tasks

A deployment lifecycle operation on a target resource is often dependent on a certain set of conditions that must exist on the target. This set of pre-existing conditions is known as the environment. If successful deployment lifecycle operations are dependent on a certain set of pre-existing conditions (environment), then the SDD specification must support the ability to specify the required environment.

Projected changes to environment

The SDD specification must support the definition of environment changes that become effective once the lifecycle operation is complete.

Solution instance variability

The SDD specification must support the definition of the appropriate information for a runtime to vary the ways in which the solution can be deployed. This information is also needed to enable an integrator to control the variability according to the needs of their higher-level solution.

This variability includes the information to control (1) the subset of capability that can be deployed; (2) setting the initial configuration of the solution; and (3) varying the topology in which the solution can be deployed.

Solution composition

The SDD specification must support the ability for the author to compose solution packages from multiple components, products, or solutions.

Solution and packaging identity

The SDD specification must support the definition of identity information for the solution package, resources that make up the solution, and solution itself to support use cases including asset management, license management, support/update entitlement, component reuse during development, reports and queries from a package repository, identifying associated documentation, solution lifecycle management, traceability to build/development environment and problem management systems, correlation into the hosting environment, component reuse, and maintenance history. Also, the SDD specification must support the definition of the identity description information used by a runtime to assist a user in making correct decisions about solution installation. The SDD specification must support the definition of the information that uniquely identifies the SDD descriptor and the ability to identify the version of the SDD. The customer should be able to identify the solution packages with consistent names.

Physical packaging

Physical packaging information should be contained in a separate media descriptor. The deployment model for a solution should be decoupled from the details of physical packaging. The format and structure of the physical packaging is outside the scope of SDD v1.0.

Interoperability with existing software packaging technologies

The SDD specification must support the ability for the author to compose solutions from existing software packages that do not have an SDD. This means that the SDD should be able to describe existing software packages.

Conform to external standards

The SDD specification must provide for alternative descriptive text to be defined for any images, animations, or