Roman, Can I forward the following to the list? Freek All, Roman created an update to the AutoGOLE topology. This lead to an off-list discussion regarding the namespaces. Since this may be relevant to the group, I would like to take this discussion on-list. Freek -------- Original Message -------- Subject: Re: [Nml-wg] Notes for teleconference Feb 16 Date: Fri, 17 Feb 2012 15:53:09 +0100 From: Roman Łapacz <romradz@man.poznan.pl> To: Freek Dijkstra <Freek.Dijkstra@sara.nl> CC: Jeroen van der Ham <vdham@uva.nl>, Jason Zurawski <zurawski@internet2.edu> Freek suggested:
* Use NML namespace over NML-NSI namespace where possible
Roman:
nml-nsi:port indicates that the port element represents NSI's STP nml-nsi:link indicates that the link element represents NSI's SDP nm-nsi:network indicates that the network element represents NSI's nsnetwork All three things are specific to NSI so I would keep their nsi namespaces to stress that.
Freek:
I understand your point, and agree that is may be beneficial to denote somehow that these are SDP or STP to NSI.
However, would using a different namespace not defeat the purpose of NML of having a single schema that everyone uses?
(Also, I'm not sure if that should be in the topology; I'm actually hoping that we can keep the topology clean from control plane information, and have the the control plane simply refer to the topology.)
Roman:
I see your point. Just one basic NML namespace would be an ideal situation. But still think that extensions/namespaces should be allowed to assign more and specific information to the basic NML elements. The NSI application(s) may want such extension to easily identify NSI abstract connections or points.
Freek:
I was perhaps a bit quick in saying "let's use NML (base) namespace everywhere". I don't know what the best option is. I try to make up my mind as we discuss this.
It is certainly possible to overload (subclass? I'm not sure about the correct term here) a namespace to let's say include NSI-specific attributes next to the regular NML-attributes.
However, I see a big risk there: in the past we have been discussing the option to overload (subclass?) a namespace for the purpose of differentiating between different technologies (Ethernet, WDM, ...). I don't see a clean way to put something in both a nml-nsi AND a nml-ethernet namespace. Unless we are creating nml-base, nml-nsi, nml-ethernet, and also nml-nsi-ethernet namespaces. I have a feeling that that solution does not scale. What if tomorrow some policy working group comes along, and we have to create a nml-nsi-ethernet-public and nml-nsi-ethernet-restricted namespace (or whatever someone may come up with).
In programming patterns, I think we need to use has-a instead of is-a (a Port has-a STP-attribute, rather than a Port is-a STP).
Here is my current thinking.
I understand there is a need for NSI (and perhaps others) to tag a given port as being a "STP", and perhaps it should go in the topology. It actually is a matter how to refer to it. The option above tags certain ports as "an STP" by being in a different namespace. My thought (hope) was that the NSI protocol could add a tag somewhere like this:
If we allow adding new tags as extensions in any place in the structure then we don't have too much control over the structure. Generic parsers will not know how to interpret such unexpected (not included in the base NML schema) changes. On the contrary, namespaces as extensions allow parsers to, at least, understand their standard properties, others would be ignored. The structures defined in the base NML schema are still followed. (Of course it is possible to define a schema in such way that any element could be inserted in any place but I don't think it's the right direction). Roman
<nml:topology id="1234"> .... <!-- regular NML topology info --> ... <nsi:stp-list> <nml:port idref="...."/> <nml:port idref="...."/> <nml:port idref="...."/> </nsi:stp-list> </nml:topology> <nsi:domain> <contact> <vCard> </contact> <controller> <url>http://example.net/webservices/NSI-controller</url> <topology idref="1234"/> <controller> </nsi-domain>