RE: Restricting relationship types to node types and node types with capability types.

[<paul.m.jordan@bt.com>]

Chris,

 

Thanks for taking the time on this. There is nothing wrong with what you have done here. My problem occurred when expanding this pattern to larder numbers of extension nodes:

 

There will be many node_types derived_from MetricABE in the same way as you have done for MetricDefinition.

Many pairs of these derived node types will have a relationship between them and that relationship has its own name.

In order to create all those relationships with different names, there will many relationship_types derived_from NodeIsExtendedBy in the same way as you have done for MetricDefinitionMeasures.

I will need to restrict the use of each of these relationship types to the specific pair of node_types which use that name.

 

You have achieved that using the MetricDefinitionExtention capability type. My point is that all these capabilities would be defined only for this job which adds about 30% more lines to the template. I could avoid all that if a revised syntax allowed me to restrict the application of the relationships by referencing the node_type rather than referencing a capability_type within the node type.

 

Regards

 

Paul Jordan
OSS Specialist
BT Technology | Tel +44 (0) 3316252643  | paul.m.jordan@bt.com

This email contains information from BT that might be privileged or confidential. And it's only meant for the person above. If that's not you, we're sorry - we must have sent it to you by mistake. Please email us to let us know, and don't copy or forward it to anyone else. Thanks.

We monitor our email systems and may record all our emails.
British Telecommunications plc
R/O : 81 Newgate Street, London EC1A 7AJ
Registered in England: No 1800000

 

 

 

From: Chris Lauwers <lauwers@ubicity.com>
Sent: 30 November 2020 19:59
To: Jordan,PM,Paul,TNK6 R <paul.m.jordan@bt.com>; tosca-comment@lists.oasis-open.org
Subject: RE: Restricting relationship types to node types and node types with capability types.

 

Hi Paul,

 

Iâm attaching a very rudimentary TOSCA template that starts to implement your pattern for the SID Metric ABE. It shows how relationship types can be refined by limiting valid_target_types to derived types of the NodeExtension capability type.

 

Iâd love to work with you to flesh this out further if youâre interested.

 

Thanks,

 

Chris

 

From: Chris Lauwers
Sent: Sunday, November 29, 2020 6:15 PM
To: paul.m.jordan@bt.com; tosca-comment@lists.oasis-open.org
Subject: RE: Restricting relationship types to node types and node types with capability types.

 

Thanks Paul, weâll take this up for review. In the meantime, a couple of additional comments:

 

• If we were to rename the âvalid_target_typesâ keyword, then perhaps âvalid_target_capability_typesâ may be the more accurate description.
• As we discussed, I believe your pattern can be supported by subclassing capability types. You mentioned that might be too cumbersome, but Iâll try to work through your example to get a feel for how bad it really is 😊

 

Thanks again for all your helpful feedback.

 

Chris

 

From: tosca-comment@lists.oasis-open.org <tosca-comment@lists.oasis-open.org> On Behalf Of paul.m.jordan@bt.com
Sent: Wednesday, November 25, 2020 3:19 AM
To: tosca-comment@lists.oasis-open.org
Subject: [tosca-comment] Restricting relationship types to node types and node types with capability types.

 

At present relationship type definitions may contain a restriction to limit their application to node types which contain one or more of the specified capability types. Currently the name of this keyword is valid_target_types which is somewhat inaccurate and could be confusing.

 

Furthermore I have a pattern for node extension which would benefit from an additional limitation on relationship types so that they were only applicable to specified node types.

 

Therefore I propose that relationship type definition is amended as follows:

 

Keyname	Required	Definition/Type	Description
â
valid_target_types	No	list of string	This keyname is deprecated; valid_target_node_capabilities is now preferred. An optional list of one or more names of Capability Types that must exist within nodes which are valid targets for this relationship. If undefined, target nodes may have any or no Capability Types defined.
valid_target_node_capabilities	no	list of string	An optional list of one or more names of Capability Types that must exist within nodes which are valid targets for this relationship. If undefined, target nodes may have any or no Capability Types defined.
valid_target_node_types	no	list of string	An optional list of one or more names of Node Types that are valid targets for this relationship. If undefined, all Node Types are valid targets.

 

If both valid_target_node_types and valid_target_node_capabilities are specified then they would be ANDed, i.e. the relationship type would be applicable only to a nodes of the specified type if it had one or more of the specified capabilities.

 

Paul Jordan
OSS Specialist
BT Technology | Tel +44 (0) 3316252643  | paul.m.jordan@bt.com

This email contains information from BT that might be privileged or confidential. And it's only meant for the person above. If that's not you, we're sorry - we must have sent it to you by mistake. Please email us to let us know, and don't copy or forward it to anyone else. Thanks.

We monitor our email systems and may record all our emails.
British Telecommunications plc
R/O : 81 Newgate Street, London EC1A 7AJ
Registered in England: No 1800000