Proposal for get_property based on discussion in WG on 2019_09

A BNF definition:

get_property: [ <modelable_entity_name> <in_node_path> <property_name> <nested_property_key_index_regexp> ]

<modelable_entity_name> ::= <node_template_name>, |

<relationship_template_name>, |

SELF, |

SOURCE, |

TARGET,

<in_node_path> ::= CAPABILTY, <capability_name>, |

REQUIREMENT, <requirement_name>, CAPABILITY, |

REQUIREMENT, <requirement_name>, NODE, <in_node_path> |

REQUIREMENT, <requirement_name>, RELATIONSHIP, |

<nested_property_key_index_regexp> ::= <property_name_regexp>, <nested_property_key_index_regexp> |

<key_regexp>, <nested_property_key_index_regexp> |

<index_regexp>, <nested_property_key_index_regexp> |

Note1: The <in_node_path> can be recursive, allowing us to traverse the target node of the requirement, and further.

Note that we can also access the properties specific for the targeted capability of a requirement.

Finally, we can access properties of the relationship created by the requirement.

Note2: The in_node_path where we traverse the requirement des not need to contain any name of the node or capability

or relationship since they are the specific one matched by the requirement.

Note3: We could also extent get_property to access a complex property fields via regexps. This could allow to access

a subfield at some level in the property, without having to name explicitly the field hierarchy. Note that the

<property_name_regexp> is mateched against all properties of that level in the complex datatype. The <key_regexp> is

matched against all the keys in the map, and the <index_regexp> against all indexes in the list.

Note4: We should deprecate the old form of get_propery, but even so, an orchestrator can recognize and still support

the old form even when implementing the new form.

BR,

/Calin

tosca message