[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Proposal for get_property based on discussion in WG on 2019_09_17
Hi Calin, This addresses a lot of the problems with the current âTOSCA pathâ expressions. However, Iâd also like to see a way to identify a specific relationship/requirement when there are multiple âoccurrencesâ of that
relationship. Perhaps we should discuss this in the context of a general discussion about âmultiple instancesâ we urgently need to have. Thanks, Chris From: tosca@lists.oasis-open.org [mailto:tosca@lists.oasis-open.org]
On Behalf Of Calin Curescu 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 |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]