# Assumptions - Customer Facing Service Specification (CFSS) named "ParentService" with 1 service characteristic "char0.1". - Resource Facing Service Specification (RFSS) named "ChildService1" with 2 service characteristics "char1.1" and "char1.2". - RFSS named "ChildService2" with 1 service characteristic "char2.1". # Current Scenario During service design, the designer selects that _ParentService_ is a bundle. The designer appoints _ChildService1_ and _ChildService2_ to that bundle. Once, these 2 RFSSs made it to the _serviceSpecRelationship_ property of ParentService, then their characteristics were reflected in the parent Service Specification. The _ParentService_ characteristics' names would be: - char0.1 - ChildService1::char1.1 - ChildService1::char1.2 - ChildService2::char2.1 > Note the {child_service_name}::{child_service_characteristic} notation for characteristics transition from child -> parent. During runtime, if any characteristic of any child changed, then this would affect the characteristic value of the child (e.g. "char1.1" of ChildService1), but would also reflect in the respective characteristic value of the parent (e.g. "ChildService1::char1.1" of ParentService). **child -> parent** Accordingly, if any characteristic (that would refer to a child) of the parent changed, then this would affect the characteristic value of the parent (e.g. "ChildService2::char2.1" of ParentService), but would also reflect in the respective characteristic value of the child (e.g. "char2.1" of ChildService2) **parent -> child** Taking the above into account, someone could design LCM rules either on the child or the parent service with the same effect (when it came to monitoring/changing characteristics' values) # Targeted Scenario The current process creates a magnitude of characteristics at the parent service (copy of every child's characteristics). The above issues emerge: - Parent (CFS) service has a view of all child (RFS) characteristics, which shouldn't be an appropriate behavior - Difficulty in distinguishing specific interesting child characteristics at the parent's scope - Parent service characteristics may have very lengthy/unprocessable names based on the depth of the relationships and the children's service names. In the targeted scenario, the service characteristics will __not__ be transitioned automatically from parent <-> child. The characteristics' transition will be part of the LCM of the service and the respective rules will be utilized. Note: When a supervision rule is trigger in a child service (when a characteristic changes), it is also triggered to the parent service. *This way, parent is made aware of a child's characteristic change* and can get the new value following the section below. **Child -> Parent** A block will be developed in Blockly, in which the Parent Service will have access to the related Children Services' characteristics (getter). A specific characteristic of the Child service will be required by this block and copied to the Parent service. **Parent -> Child** A block will be developed in Blockly, in which the Parent Service will set a list of characteristics (and values) to the related Children Services.