Hi, I'm reviewing the NML document a few times in detail, adding notes what examples are useful. One thing I can't seem to do is distinguish between the Ports that can be configured by an AdaptationService and the Ports are are already configured. The providesPort relation seem to aim the ports that are already configured, akin to providesLink for the SwitchingService. Current situation ================= Here are the current attributes and relations for SwitchingService: - associate with static component: Node|Topology --(hasService)--> SwitchingService - associate (between) which (ports a) link CAN be created: SwitchingService --(hasOutboundPort)--> Port|PortGroup SwitchingService --(hasInboundPort)--> Port|PortGroup - associate which links are already configured: SwitchingService --(providesLink)--> Link|LinkGroup Here are the current attributes and relations for AdaptationService: - associate with static component: Port --(hasService)--> AdaptationService - associate which (client layer) ports CAN be created: AdaptationService --adaptationfunction--> URI (*) N/A - associate which ports are already configured: AdaptationService --(providesPort)--> Port|PortGroup (* The adaptationfunction attribute can be used to determine client layer encoding, but not the available labels) Here are three (3) proposals to rectify this omission and subsequently align the SwitchingService and AdaptationService definitions: Proposal 1: encoding and hasLabelGroup ====================================== For SwitchingService (same as current situation): - associate with static component: Node|Topology --(hasService)--> SwitchingService - associate (between) which (ports a) link CAN be created: SwitchingService --(hasOutboundPort)--> Port|PortGroup SwitchingService --(hasInboundPort)--> Port|PortGroup - associate which links are already configured: SwitchingService --(providesLink)--> Link|LinkGroup For AdaptationService (add attribute and relation): - associate with static component: Port --(hasService)--> AdaptationService - associate which (client layer) ports CAN be created: AdaptationService --encoding--> URI AdaptationService --hasLabelGroup--> LabelGroup - associate which ports are already configured: AdaptationService --(providesPort)--> Port|PortGroup Proposal 2: canProvidePort ========================== For SwitchingService (same as current situation): - associate with static component: Node|Topology --(hasService)--> SwitchingService - associate (between) which (ports a) link CAN be created: SwitchingService --(hasOutboundPort)--> Port|PortGroup SwitchingService --(hasInboundPort)--> Port|PortGroup - associate which links are already configured: SwitchingService --(providesLink)--> Link|LinkGroup For AdaptationService (add canProve): - associate with static component: Port --(hasService)--> AdaptationService - associate which (client layer) ports CAN be created: AdaptationService --canProvidePort--> Port|PortGroup - associate which ports are already configured: AdaptationService --(providesPort)--> Port|PortGroup Proposal 2: canProvidePort ========================== For SwitchingService (same as current situation): - associate with static component: Node|Topology --(hasService)--> SwitchingService - associate (between) which (ports a) link CAN be created: SwitchingService --(hasOutboundPort)--> Port|PortGroup SwitchingService --(hasInboundPort)--> Port|PortGroup - associate which links are already configured: SwitchingService --(providesLink)--> Link|LinkGroup For AdaptationService (add canProvidePort): - associate with static component: Port --(hasService)--> AdaptationService - associate which (client layer) ports CAN be created: AdaptationService --canProvidePort--> Port|PortGroup - associate which ports are already configured: AdaptationService --(providesPort)--> Port|PortGroup Proposal 3: Behave like a SwitchingService ========================================== For SwitchingService (has[In|Out]boundPort is replaced with canConnect[Sink|Source]Port): - associate with static component: Node|Topology --(hasService)--> SwitchingService - associate (between) which (ports a) link CAN be created: SwitchingService --(canConnectSinkPort)--> Port|PortGroup SwitchingService --(canConnectSourcePort)--> Port|PortGroup - associate which links are already configured: SwitchingService --(providesLink)--> Link|LinkGroup For AdaptationService (it now is provided by a Node or Topology): - associate with static component: Node|Topology --(hasService)--> AdaptationService AdaptationService --(hasServerSinkPort)--> Port AdaptationService --(hasServerSourcePort)--> Port - associate which client AND server layer ports CAN be created: AdaptationService --(canConnectClientSinkPort)--> Port|PortGroup AdaptationService --(canConnectClientSourcePort)--> Port|PortGroup - associate which ports are already configured: AdaptationService --(providesClientSinkPort)--> Port|PortGroup AdaptationService --(providesClientSourcePort)--> Port|PortGroup The advantage of the later configuration is that is allows bidirectional adaptations services (no more distinction between AdaptationService and DeAdaptationService). With only minor modifications it is also possible to support inverse multiplexing adaptation. I did not add this, because I'm not a big fan (it adds more complexity, which can be provided with the more simple experimental isParallelCompoundLink relation.) My opinion ========== I would say proposal #2 is cleanest. What do you think? Freek