Hi, You are absolutely right, as we envision the logical order of nesting: Topology - Node - Port - Link. So therefore it should be as you said. Jeroen. On 21 Aug 2012, at 15:14, Roman Łapacz <romradz@man.poznan.pl> wrote:
Hi,
I've analysed the list of relations in artf6547 and it seems that the following snippet (taken from the example file I recommended in my previous email) is wrong:
<nml:Link id="urn:ogf:network:domainy.net:2012:B-to-C"> <nml:Relation type="http://schemas.ogf.org/nml/2012/10/relation/hasSource"> <nml:Port idRef="urn:ogf:network:domainy.net:2012:B:port_ge-1.0.8.1501-out"/> </nml:Relation> <nml:Relation type="http://schemas.ogf.org/nml/2012/10/relation/hasSink"> <nml:Port idRef="urn:ogf:network:domainy.net:2012:C:port_ge-5.2.7.1501-in"/> </nml:Relation> </nml:Link>
It uses hasSource/hasSink relations but according to the list only isSource/isSink are permitted. So the structure should be transformed into:
<nml:Port id="urn:ogf:network:domainy.net:2012:B:port_ge-1.0.8.1501-out"> <nml:Relation type="http://schemas.ogf.org/nml/2012/10/relation/isSource"> <nml:Link idRef="urn:ogf:network:domainy.net:2012:B-to-C"/> </nml:Relation> </nml:Port>
<nml:Port id="urn:ogf:network:domainy.net:2012:C:port_ge-5.2.7.1501-in"> <nml:Relation type="http://schemas.ogf.org/nml/2012/10/relation/isSink"> <nml:Link idRef="urn:ogf:network:domainy.net:2012:B-to-C"/> </nml:Relation> </nml:Port>
<nml:Link idRef="urn:ogf:network:domainy.net:2012:B-to-C"> </nml:Link>
Am I right? Roman
W dniu 2012-08-21 12:36, Roman Łapacz pisze:
W dniu 2012-08-17 16:49, Jeroen van der Ham pisze:
Hi,
Thanks for the examples!
Only thing that I see is that you wrote "lacatedAt".
Then again, I'm not entirely sure that we need that Relation.
Updated. Now it's implicit. Also I've updated SwitchingService adding relations (hasInboundPort, hasOutboundPort) to the Node. Previously I didn't do that because I thought that their presence in the SwitchingService element was enough. But now I'm thinking that the service does not have to include all ports existing in the node so the contents of SwitchingService and Node may be different (in this example they are the same).
I've made some changes in two example files which in my opinion could be used as appendixes in the doc (present nicely how a complete nml topology file may look like). Please, take a look at them to make sure everything is OK.
https://forge.ogf.org/svn/repos/nml-examples/201207-groups-and-labels/groups... https://forge.ogf.org/svn/repos/nml-examples/201207-compoundlink/serial-comp...
Roman
I've tried to make a list of the implicit relations that I see, and I came to the following:
- hasTopology - hasNode - implementedBy - hasService - hasPort - hasLabel - hasLabelGroup - hasLink - locatedAt - existsDuring
Is that list complete?
Jeroen.
On 17 Aug 2012, at 16:09, Roman Łapacz<romradz@man.poznan.pl> wrote:
Hi,
attached a draft of Example section (for now it's MS Word document). I tried to make it as simple and clear as possible. Structures are not to heavy and names are very general. Waiting for comments
thanks, Roman <Examples-doc-20120814.docx>_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg