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. 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