W dniu 2012-03-12 22:43, Jason Zurawski pisze:
Hi Roman/All;
I would rather let the namespace tell you information about 'layers' if possible, this is how we treat other elements (e.g. same namespace = same layer, different namesapces a merge in layers). If we do this, I believe the relationship doesnt need a specific 'name' or 'action', but I haven't thought about the implications fully.
Right. I like namespaces for layers as well but what if we have to have layers (hierarchy) which in fact represent the same category. An example I'm thinking is an aggregation. Roman
Thanks;
-jason
On 3/12/12 3:39 PM, thus spake Roman Łapacz:
Because of this, I would claim that a public/private topo are both at the same 'level', and can be related, and shouldn't be defined within each other.
Do you mean same XML 'level'? e.g.:
<nml:Topology id="aaaaaaa"> <nml:Relation type="hasSubtopology"> <nml:Topology idRef="urn:ogf:network:a.net:subtopo"/> </nml:Relation> ... </nml:Topology> <nml:Topology id="urn:ogf:network:a.net:subtopo"> ... </nml:Topology>
Yes, basically have them be defined independently and linked later as you note here. 2 quick use cases:
Can we say that we may have two options of joining the topologies: 1) horizontally (the same layer) and 2) vertically (different layers)
example for 1) <nml:toplogy id="urn:ogf:network:a.net:topoX""> <nm:relation type="merge"> <nml:toplogy idRef="urn:ogf:network:a.net:topoY"/> </nm:relation> </nml:topology>
I use the word "merge" but it could be something different.
example for 2) <nml:toplogy id="urn:ogf:network:a.net:topoX""> <nm:relation type="adaptation"> <nml:toplogy idRef="urn:ogf:network:a.net:subtopoX"/> </nm:relation> </nml:topology>
I hope I understand "adaptation" the right way (again, this could be a different name). This relation type could be used each time we want to have sub-layers (for example, also for ports or links).
It would be up to a user/application which topology element/container is shared.
Roman