
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>

Hi all, A port can have many properties. It can be abstract, Ethernet, (NSI) domain boundary port, have restricted access, be part of a link bundle. What I want to avoid is having to deal with namespaces and objects such as <nml-nsi-ethernet-restricted-lacp:port>
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).
The RNC schema you created last year DID allow arbitrary elements inside NML elements. I think I misunderstand you. In particular, I do not understand the sentence "namespaces as extensions allow parsers to, at least, understand their standard properties." Are you talking about chameleon namespaces? I assume that: * NML elements can contain arbitrary child elements, from the NML or other namespace * if a parser encounters an unknown element from a known namespace, it should stop and return an error * if a parser encounters an element from a unknown namespace, it should ignore it (or -if we define chameleon namespaces- interpret as if it was part of the base namespace) (Note that in this case, I'm unclear how a parser should distinguish between a chameleon namespace and a proprietary namespace which can safely be ignored.) Could you perhaps give an example of a message containing NML and NSI information, and explain how a parser which only understands NML sees it, and how a parsers understands both NML and NSI sees it, and if either should ignore unknown elements or stop and return an error? Freek

W dniu 2012-02-17 16:28, Freek Dijkstra pisze:
Hi all,
A port can have many properties. It can be abstract, Ethernet, (NSI) domain boundary port, have restricted access, be part of a link bundle.
What I want to avoid is having to deal with namespaces and objects such as<nml-nsi-ethernet-restricted-lacp:port>
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). The RNC schema you created last year DID allow arbitrary elements inside NML elements.
I think I misunderstand you. In particular, I do not understand the sentence "namespaces as extensions allow parsers to, at least, understand their standard properties."
a very simple example <nml-ext:x> <nml:y></nml:y> <nml-ext:z></nml-ext:z> </nml-ext:x> A parser which does not understand the nml-ext extension/namespace would treat x as nml:x (of course if nml:x exsits) and ignore nml-ext:z. Roman
Are you talking about chameleon namespaces?
I assume that:
* NML elements can contain arbitrary child elements, from the NML or other namespace * if a parser encounters an unknown element from a known namespace, it should stop and return an error * if a parser encounters an element from a unknown namespace, it should ignore it (or -if we define chameleon namespaces- interpret as if it was part of the base namespace) (Note that in this case, I'm unclear how a parser should distinguish between a chameleon namespace and a proprietary namespace which can safely be ignored.)
Could you perhaps give an example of a message containing NML and NSI information, and explain how a parser which only understands NML sees it, and how a parsers understands both NML and NSI sees it, and if either should ignore unknown elements or stop and return an error?
Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg

Guys- If you are considering which parsers will process the constructs then you are already way past where you need to be. I would implore you to make the specification so simple that the standard is not based on nor is concerned about parser implementations. Jerry On 2/17/12 10:45 AM, Roman Łapacz wrote:
W dniu 2012-02-17 16:28, Freek Dijkstra pisze:
Hi all,
A port can have many properties. It can be abstract, Ethernet, (NSI) domain boundary port, have restricted access, be part of a link bundle.
What I want to avoid is having to deal with namespaces and objects such as<nml-nsi-ethernet-restricted-lacp:port>
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). The RNC schema you created last year DID allow arbitrary elements inside NML elements.
I think I misunderstand you. In particular, I do not understand the sentence "namespaces as extensions allow parsers to, at least, understand their standard properties."
a very simple example
<nml-ext:x> <nml:y></nml:y> <nml-ext:z></nml-ext:z> </nml-ext:x>
A parser which does not understand the nml-ext extension/namespace would treat x as nml:x (of course if nml:x exsits) and ignore nml-ext:z.
Roman
Are you talking about chameleon namespaces?
I assume that:
* NML elements can contain arbitrary child elements, from the NML or other namespace * if a parser encounters an unknown element from a known namespace, it should stop and return an error * if a parser encounters an element from a unknown namespace, it should ignore it (or -if we define chameleon namespaces- interpret as if it was part of the base namespace) (Note that in this case, I'm unclear how a parser should distinguish between a chameleon namespace and a proprietary namespace which can safely be ignored.)
Could you perhaps give an example of a message containing NML and NSI information, and explain how a parser which only understands NML sees it, and how a parsers understands both NML and NSI sees it, and if either should ignore unknown elements or stop and return an error?
Freek _______________________________________________ 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

W dniu 2012-02-17 16:53, Jerry Sobieski pisze:
Guys-
If you are considering which parsers will process the constructs then you are already way past where you need to be.
No, no, we are not talking about parser implementations but how nml elements could be interpreted. Roman
I would implore you to make the specification so simple that the standard is not based on nor is concerned about parser implementations.
Jerry
On 2/17/12 10:45 AM, Roman Łapacz wrote:
W dniu 2012-02-17 16:28, Freek Dijkstra pisze:
Hi all,
A port can have many properties. It can be abstract, Ethernet, (NSI) domain boundary port, have restricted access, be part of a link bundle.
What I want to avoid is having to deal with namespaces and objects such as<nml-nsi-ethernet-restricted-lacp:port>
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). The RNC schema you created last year DID allow arbitrary elements inside NML elements.
I think I misunderstand you. In particular, I do not understand the sentence "namespaces as extensions allow parsers to, at least, understand their standard properties."
a very simple example
<nml-ext:x> <nml:y></nml:y> <nml-ext:z></nml-ext:z> </nml-ext:x>
A parser which does not understand the nml-ext extension/namespace would treat x as nml:x (of course if nml:x exsits) and ignore nml-ext:z.
Roman
Are you talking about chameleon namespaces?
I assume that:
* NML elements can contain arbitrary child elements, from the NML or other namespace * if a parser encounters an unknown element from a known namespace, it should stop and return an error * if a parser encounters an element from a unknown namespace, it should ignore it (or -if we define chameleon namespaces- interpret as if it was part of the base namespace) (Note that in this case, I'm unclear how a parser should distinguish between a chameleon namespace and a proprietary namespace which can safely be ignored.)
Could you perhaps give an example of a message containing NML and NSI information, and explain how a parser which only understands NML sees it, and how a parsers understands both NML and NSI sees it, and if either should ignore unknown elements or stop and return an error?
Freek _______________________________________________ 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
participants (3)
-
Freek Dijkstra
-
Jerry Sobieski
-
Roman Łapacz