Major Current examples show the dependsOn RelationionshipType defined with a RequirementType on the source end and and CapabilityType on the remote end. This syntax forces someone wanting to use a dependsOn relation in a Service Template to have to a add a capability to the target NodeType if it does not yet have one, resulting in a change in the target's NodeType definition. In addition to being convenient and unnecessary, the "owner" of the target type may not expect users to be changing his/her type when they use it in Service Templates. From a type evolution perspective, this causes a change in the target NodeType, making it a different version than it original definition, which is not the intention (the user is not trying to change any of the semantics of the target NodeType).
The spec has been written that way because at that time we thought it would be best to keep it symmetric, i.e. when you depend on a capability, you have a requirement OR it is two nodes that depend on each other. We can of course discuss to relax this.
I think Derek's original proposal would go in this direction.
@Derek: in the call where you presented this, I think you had an even crisper formulation of the proposal. Do you remember it?
Wouldn't it make sense to remove source/target type restrictions from DependsOn completely?
It seems like it should allow either Node Type of capability type.
I have been looking at similar things and have come across situations where I'd like to intermix Requirement \ Capability Type with Node Types in the source and target. Why does the spec say that you can't do that?