Comments on spec SDD Spec R14

[Christine Draper <cdraper@us.ibm.com>]

Issue #1 is the one I think is most significant.


CONCEPTUAL/SCOPE ISSUES

1. resource.selection attribute and conditionally required/resulting resources (Issue 35 & hostedResource description)

The semantics of the submission was that a hostedResource (or componentResource) is only "potential" unless an IU is actually installed that has a required or resulting reference to the resource.

I think the current proposal is to replace this with semantics specifying that a hostedResource element is always required, if the parent is required.

If we do this, then we still need a way to specify that a hosted resource is conditionally needed. There is also the problem of what this means if the hostedResource element is (or may be) a resulting resource only.

Options:

1. A resource that is only conditionally required (or that is newly created) must be defined at the top level of the topology, with a HostedBy relationship to its potential hosting environment. hostedResource is only used for a resource that is always required if its parent is.
2. We change the default semantics of "selection" attribute, so that anyone needing a conditional hosted resource has to specify that attribute. I think this one's dangerous, because SDD authors just won't realize (i.e. it will lead to interop problems, because some runtimes won't enforce and some will; and I think that many SDDs with selectable content will need conditional hosted resources).
3. We go one step further than (1), and get rid of hostedResource and componentResource all together, and just use relationship constraints. If a hosted resource is required whenever its parent is required, specify a Hosts constraint on the parent. If it is only conditionally required, specify a HostedBy on the required resource.
4. We leave the semantics as in the submission.

(3) has some appeal because it means we don't have to handle hosts and hasComponent relationship types specially (and in two different ways). I think it is less likely to lead to SDD authors making mistakes than (1) or (2). But it is a significant departure from the approach that we've validated with the IUDD work, so it would need more scrutiny to be sure it works.

2. resource.custom constraint (Issue 27)

I do not believe that "custom" should be replaced by an extensibility point.  There are two different concepts:

1. An ability for the SDD author to provide some code that can be executed in the target hosting environment to perform a check. As long as a runtime can access the target hosting environment, it is guaranteed to be able to perform the check.
2. The ability to define new types of check. If the runtime does not recognize the check, it cannot perform it.

We may need to support (2), but the interop characteristics are very different.

3. resource.checks element (Issue 40)

Originally, I thought this element would be used rarely (as in the annotation), and only for checks which are not used in requirements. 

In practice, people have used it more extensively. If there is a constraint that needs to be applied as a requirement of multiple (but not all) IUs, then defining a check and referencing it in the requirement is the natural thing to do. So unless we are excluding selectability from the first conformance level, I think we need to keep checks in. Either way, we need to get rid of the words about it being rare.

4. resource.full attribute (Issue 38)

If we don't include this attribute, we need to specify the appropriate semantics for constraints defined in a resource - i.e. does an SDD contain a complete description of the requirements this solution has on a given resource, or not?

Options:

1. It must always contain a complete description. This would be onerous for authors of simple updates and fixes, and make processing of these complex. I dont recommend this.
2. It contains a description of the additional (incremental) requirements - i.e. of the requirements related to the operations supported by the SDD. This is the current default, and so would make it easy to add "full" at a later point. What you can't do (unless "full" attribute is supported) is know for sure the "lifetime" requirements of the runtime resource, because it's not possible to reason that "there is no longer a requirement for DLL X after you have applied Version Y"; or that "requirement for db name A version B has been replaced with db name C version D". I'd recommend this.

OTHER/DOCUMENTATION ISSUES

5. connectivity.direction (Issue 28)

A default would be a good idea, but it's hard to say which. Seems like it shouldn't be "both", because that may often be too permissive.   The choice between inbound and outbound feels arbitrary/symmetrical.

6. resource.relationship constraint

We will need to explicirly define which way round the relationship constraint goes.  If I have a resource X and I give it a relationship constraint of type "Uses" with related resource ref Y, then X Uses Y is the constraint.

We will also need to explain (non-normative?) when to  specify "Y UsedBy X" instead of  "X Uses Y".    This will depend on the resolution of the discussion above on conditional resource constraints. 
7. resource.property.value (Issue 26)

The reason for the difference between property.value and property.listOfValues.value was because the first supported pattern-match for a single- or multi-valued property,  whereas the second was intended for specifying a  list of expected values for a multi-value property.  I can't think of a good use case for needing a list of expected pattern matches (and the semantics would be hard to define - do they need to be matched by unique, distinct elements?).

We might make this clearer by having:
property.value : VariableExpression	(explicit value that a specified single-valued property must satisfy)
property.multiValue.value : VariableExpression (one or more explicit values that a specified multi-value property must satisfy)
property.patternedValue : Pattern (pattern match that a  specified single-valued property must satisfy)

and then we'd need to decide if there was a need for: 
property.multiValue.patternedValue : Pattern (single pattern match to be satisfied by one or more elements of the multi-valued property)

8. resource.version constraint and GenericVersionString

We need to define the valid contents of version, even though the schema will point to VariableExpression. GenericVersionStringType used to do this - I think it needs to be put back in the schema, or the same set of rules defined in the spec.

Version comparison algorithm needs updating to handle the fact that 1.1 is the same as 1.1.0.0.

9. ConstraintSet

An alternative should define one or more constraints, not zero or more.

Senior Technical Staff Member
IBM, 11501 Burnet Road, Mail Point 901-6B10
Austin, TX 78758
1-512-838-3482 tl 678-3482