[Nml-wg] hasSource/hasSink vs. isSource/isSink

[Jeroen van der Ham]

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 at 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-and-labels.xml
>>  https://forge.ogf.org/svn/repos/nml-examples/201207-compoundlink/serial-compound.xml
>> 
>> 
>> 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 at 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 at ogf.org
>>>> https://www.ogf.org/mailman/listinfo/nml-wg
>> 
>> 
>> 
>> _______________________________________________
>> nml-wg mailing list
>> nml-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/nml-wg
> 
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg