Arbitrary and Cascading
Operations
CL2 Issues #7 & #8
The Problem
• Performing an operation on the SDD as a whole does
not necessarily mean performing that same operation on
all content elements in scope. It also doesn’t necessarily
mean performing just one operation on all content
elements in scope.
– E.g. An install at the top level may map to install operations on
installable units and configuration operations on configuration
units.
– E.g. An install at the top level may require an update, undo or
even uninstall of some of the content.
– E.g. An update at the top level may require an install of some
content.
– E.g. An install at the top level may require both an install and an
uninstall of a tool used to support the install.
There is no way to know how the top-level operation is
intended to map to operations on content elements.
Refining the problem statement:
• Maybe not all combinations of top-level operations should be
allowed in the same SDD in version 1 of the spec.
• Maybe not all operations should be allowed for all package types.
• Let’s determine which combinations of top-level operations make
sense in SDDs for each package type.
– Any type of artifact can be included in the content elements.
– This discussion is only about the allowed combinations of top-level
operations per content element.
Top-level operations supported for
packageType: baseInstall
configure
?
install
yes – OK without update?
repair
?
undo
no
update
no
Uninstall
yes
verifyConfiguration
?
verifyResults
?
Top-level operations supported for
packageType: baseUninstall
configure
install
repair
undo
update
use
uninstall
verifyConfiguration
verifyResults
yes
Top-level operations supported for
packageType: configuration
configure
install
repair
undo
update
use
uninstall
verifyConfiguration
verifyResults
yes
Top-level operations supported for
packageType: maintenance
configure
install
repair
undo
update
use
uninstall
verifyConfiguration
verifyResults
Yes – ok without update?
yes
Top-level operations supported for
packageType: modification
configure
install
repair
undo
update
use
uninstall
verifyConfiguration
verifyResults
Top-level operations supported for
packageType: replacement
configure
install
repair
undo
update
use
uninstall
verifyConfiguration
verifyResults
Top-level operations supported for
packageType: localization
configure
install
repair
undo
update
use
uninstall
verifyConfiguration
verifyResults
Proposal on Hold
On hold so we can further explore the problem.
The Solution
• Provide a way for the SDD author to state
explicitly how operations on individual
content elements map to a top level
operation.
Current semantics that may be affected…
• Operations on requirements are used to associate the
requirement with a particular artifact.
• Operations on requirements in a CompositeUnit or
CompositeInstallable associate the requirement with
artifacts of all the contained content elements (or to top
level operations in the case of ContainedPackages).
• Dependency elements allow expression of dependencies
on a particular operation applied to a particular content
element.
Solution Implementation
•
Let the CompositeInstallable state explicitly which operations are valid for
the SDD.
•
Let operations defined in the Composites map directly to the valid SDD
operations. (Specification hit only.)
•
Let each content element that defines artifacts provide a mapping between
the SDD operations and operations supported by the content element’s
artifacts.
– Let the default mapping be one-to-one so that a mapping only need be defined
when there are differences.
– Allow the mapping of multiple operations on content to one operation at the top
level.
•
Allow expression of dependencies by a one operation in a content element
on another operation in the same content element. This allows ordering of
artifact processing when multiple content element operations map to one
SDD operation. (Specification hit only.)
<complexType name="CompositeInstallableType">
<sequence>
<element name="Identity" type="sdd-common:IdentityType" minOccurs="0"/>
<element name="Condition" type="sdd-dd:ConditionType" minOccurs="0"/>
<element name="Variables" type="sdd-dd:VariablesType" minOccurs="0"/>
<element name="RequiredBase" type="sdd-dd:RequiredBaseType" minOccurs="0"/>
<element name="Requirements" type="sdd-dd:RequirementsType" minOccurs="0"/>
<element name="SupportedLanguages" type="sdd-dd:SupportedLanguagesType" minOccurs="0"/>
<element name="ResultingResource" type="sdd-dd:ResultingResourceType" minOccurs="0" maxOccurs="unbounded"/>
<element name="ResultingChange" type="sdd-dd:ResultingChangeType" minOccurs="0" maxOccurs="unbounded"/>
<element name="BaseContent" type="sdd-dd:BaseContentType" minOccurs="0"/>
<element name="SelectableContent" type="sdd-dd:SelectableContentType" minOccurs="0"/>
<element name="LocalizationContent" type="sdd-dd:LocalizationContentType" minOccurs="0"/>
</sequence>
<attribute name="id" type="ID" use="required"/>
<attribute name="operation" type="sdd-dd:OperationApplicabilityType" use="required"/>
<anyAttribute namespace="##other" processContents="lax"/>
</complexType>
Add a list of operations to CompositeInstallable as an attribute. These are the
operations that are valid for the SDD. The specification will explain that the
intent of the SDD is to support those operations applied to the SDD as a
whole. It is not the intent that any operation can be applied to any individual
content element in isolation.
Make the operation attribute required with no default to make sure the SDD
author thinks about and communicates the operations supported by the SDD.
Add an optional OperationMaps element to
InstallableUnits, ConfigurationUnits and
LocalizationUnits – the content elements that
define artifacts.
<complexType name="OperationMapsType">
<sequence>
<element name="OperationMap" type="sdd-dd:OperationMapType" maxOccurs="unbounded" />
</sequence>
</complexType>
<complexType name="OperationMapType">
<attribute name=“sddOperation" type="sdd-dd:OperationType" use="required" />
<attribute name=“contentOperations" type="sdd-dd:OperationApplicabilityType" use=“optional" />
<anyAttribute namespace="##other" processContents="lax"/>
</complexType>
Operation semantics
• The SDD operation is an input provided by the deployer. It must be
one of the operations in the set of operations defined in the
CompositeInstallable.
• For composites there is no mapping of operations. The SDD
operation is always the operation that applies to the composite.
• For content with artifacts – InstallableUnit, ConfigurationUnit and
LocalizationUnit – the SDD operation can be mapped to one or more
different operations on the content element.
– When a content element is in scope, this map is used to determine which
Requirements, Conditions, and Completion actions apply and which artifact(s)
will be used.
– When sddOperation is defined with no associated contentOperation, then that
sddOperation is a no-op for the content element.
– If no mapping is provided for a particular SDD operation, the SDD operation is
applied without mapping.
– It’s OK to provide a mapping for none, or only a subset, of the SDD operations.
SDD operations that do not have a mapping are applied without change.
Remaining operation issue:
How does operation interact with content selection?
Note: This issue is not created or solved by the proposal presented in these
slides.
• Does the selection of content by feature apply
for all operations?
– It is easy to understand how features select content
for an install.
– But what about update?
• Selection of content for an update probably should be based
on what was previously installed, not on selection of features
in the update SDD. How is this achieved?
• Does the answer change if one package can handle both
install and update?
– What about undo, uninstall, configure, verify and
verifyConfig?