W dniu 2010-12-13 16:59, Jason Zurawski pisze:
While I see you are still suggesting different namespaces for the attributes, I have not done this for the reasons I have outlined in other threads, the namespace of the attributes in my examples matches that of the surrounding elements.
<nml:node nm:id="urn:ogf:network:example.net:switchC"> <nml:hasport nm:idRef="urn:ogf:network:example.net:switchC:port6-2:ingress"/> </nml:node>
<nml:link type="link" nm:id="urn:ogf:network:example.net:segmentAB"> <nml:source nm:idRef="urn:ogf:network:example.net:switchA:port3-1:egress"/> <nml:sink nm:idRef="urn:ogf:network:example.net:switchB:port4-1:ingress"/> </nml:link>
I see the reason of different namespace if we would like to have extra attribute for ordering. But for 'id' and 'idRef' attributes I don't seee the need for different namespace.
I believe 'destination' was the term we have used in the past, but 'sink' is fine for now.
<nml:link type="crossconnect" nm:id="urn:ogf:network:example.net:crossconnect4-1_5-2"> <nml:source nm:idRef="urn:ogf:network:example.net:switchB:port4-1:ingress"/> <nml:sink nm:idRef="urn:ogf:network:example.net:switchB:port5-2:egress"/> </nml:link>
Can you re-explain what makes 'type=crossconnect' and 'type=link' necessary? I understand that this is old news for some, but I am still not sure of the distinction and why this is needed.
The type 'link' could be default one so it wouldn't be necessary to have it explicitly. Cheers, Roman