Hi Martin,
I think there are many interpretations of Service. This is also related to my other comment about the multi-layer topology in the other thread.
I think we should include an abstract Service in the base and that this Service can be extended in the various layer-specific schemata. This would allow the use of the Service element to describe all the use cases that you mentioned.
Could you elaborate? To me, the three use case I mentioned (Fixed wavelenght over a fibre, tunable laser and VLAN) have rather different properties. In NDL we specified with this with a bunch of classes (Layer, Adaptation, StaticInterface, ConfigrableInterface, PotentialInterface and InstantiatedMuxInterface plus a bunch of relations), and the three use cases had different relations and class instances. I'm glad to write out all details and sent it to the list, but I hope that your ideas may lead to less subclasses of Ports. Just as starters, which of the three use case is to be represented as a "service" (in my mind only #3 and perhaps #2 are; #1 is -to me- a topology feature, not a capability feature, and not a service), and do you like to subclass "Adaptation" from "Service", or do you like to remove the "Adaptation" class altogether from the base schema (which is what I read in the above, but somehow doubt that that is your intention). So I am VERY interested to work on your ideas, but they are yet not clear to me. So pretty please, could you make a stance at the question of Jeroen:
Could you write a proposal for this perhaps including a new version of the schema diagram? I would like to understand your proposal better.
Thanks, Freek