Hi, W dniu 2012-07-10 22:27, Freek Dijkstra pisze:
<nsi:path> <!-- Two STP, each with a source and sink: a bidirectional path --> <nsi:STP> <Network>urn:ogf:network:cesnet.cz:2012:czechlight</Network> <!-- No VLAN specified: pick any one VLAN within these Port Groups. --> <source><nml:PortGroup>urn:ogf:network:nordu.net:2012:nordunet-surfnet</nml:PortGroup></source> <sink><nml:PortGroup>urn:ogf:network:nordu.net:2012:surfnet-nordunet</nml:PortGroup></sink> </nsi:STP> <nsi:STP> <Network>urn:ogf:network:sne.science.uva.nl:2012:lighthouse</Network> <!-- No VLAN specified: pick any one VLAN within these Port Groups. --> <source><nml:PortGroup>urn:ogf:network:sne.science.uva.nl:2012:lighthouse-egress</nml:PortGroup></source> <sink><nml:PortGroup>urn:ogf:network:sne.science.uva.nl:2012:lighthouse-ingress</nml:PortGroup></sink> </nsi:STP> </nsi:path>
Freek, in your examples sent to the NSI group you didn't use idRef attribute for nml:GroupPort (or nml:Port). It's a small thing but I think we should be strict to use accepted structures. To me using tag values for this is not supported by NML at the moment (if we had xsd or rnc schema this would be verified easily). Roman
On 11-07-2012 14:10, Roman Łapacz wrote:
W dniu 2012-07-10 22:27, Freek Dijkstra pisze:
<nsi:path> <!-- Two STP, each with a source and sink: a bidirectional path --> <nsi:STP> <Network>urn:ogf:network:cesnet.cz:2012:czechlight</Network> <!-- No VLAN specified: pick any one VLAN within these Port Groups. --> <source><nml:PortGroup>urn:ogf:network:nordu.net:2012:nordunet-surfnet</nml:PortGroup></source> <sink><nml:PortGroup>urn:ogf:network:nordu.net:2012:surfnet-nordunet</nml:PortGroup></sink> </nsi:STP> <nsi:STP> <Network>urn:ogf:network:sne.science.uva.nl:2012:lighthouse</Network> <!-- No VLAN specified: pick any one VLAN within these Port Groups. --> <source><nml:PortGroup>urn:ogf:network:sne.science.uva.nl:2012:lighthouse-egress</nml:PortGroup></source> <sink><nml:PortGroup>urn:ogf:network:sne.science.uva.nl:2012:lighthouse-ingress</nml:PortGroup></sink> </nsi:STP> </nsi:path>
Freek, in your examples sent to the NSI group you didn't use idRef attribute for nml:GroupPort (or nml:Port). It's a small thing but I think we should be strict to use accepted structures. To me using tag values for this is not supported by NML at the moment (if we had xsd or rnc schema this would be verified easily).
Hi Roman, That's correct, but the above isn't NML. It is NSI which is referring to NML objects. Given that NSI does not use id/idRef I decided to use their syntax. But you are right that in that case I shouldn't have used the nml namespace if it is not NML. What do you suggest? I can understand the desire to make it a short piece of NML, but that would require introducing id/idRef, the hasInboundPort/hasOutboundPort relations, hence the nml:Relation construct. The original proposal used query parts in the URN, which is not part of NML (I'm not even sure if the query part is part of the URN or not -- see my mail http://www.ogf.org/pipermail/nml-wg/2012-July/001012.html). A further complication was that the NSI in some case want to define a Port or subset of the PortGroup within a larger PortGroup by identifying it by its label or label subset, without actually naming the result. That would require me to introduce unnamed NML objects (NML objects without a URN identifier, that are identified by their properties). I may want to do that anyway, but felt this was a bit too much wrestling if all I wanted was a reference. But by all means rewrite the examples and propose it to NML + NSI. To me this is not NML, but you have a valid argument that if this is just syntactic sugar to define a reference, why not make the sugar look like the same. Regards, Freek
W dniu 2012-07-11 14:34, Freek Dijkstra pisze:
On 11-07-2012 14:10, Roman Łapacz wrote:
W dniu 2012-07-10 22:27, Freek Dijkstra pisze:
<nsi:path> <!-- Two STP, each with a source and sink: a bidirectional path --> <nsi:STP> <Network>urn:ogf:network:cesnet.cz:2012:czechlight</Network> <!-- No VLAN specified: pick any one VLAN within these Port Groups. --> <source><nml:PortGroup>urn:ogf:network:nordu.net:2012:nordunet-surfnet</nml:PortGroup></source> <sink><nml:PortGroup>urn:ogf:network:nordu.net:2012:surfnet-nordunet</nml:PortGroup></sink> </nsi:STP> <nsi:STP> <Network>urn:ogf:network:sne.science.uva.nl:2012:lighthouse</Network> <!-- No VLAN specified: pick any one VLAN within these Port Groups. --> <source><nml:PortGroup>urn:ogf:network:sne.science.uva.nl:2012:lighthouse-egress</nml:PortGroup></source> <sink><nml:PortGroup>urn:ogf:network:sne.science.uva.nl:2012:lighthouse-ingress</nml:PortGroup></sink> </nsi:STP> </nsi:path>
Freek, in your examples sent to the NSI group you didn't use idRef attribute for nml:GroupPort (or nml:Port). It's a small thing but I think we should be strict to use accepted structures. To me using tag values for this is not supported by NML at the moment (if we had xsd or rnc schema this would be verified easily). Hi Roman,
That's correct, but the above isn't NML. It is NSI which is referring to NML objects. Given that NSI does not use id/idRef I decided to use their syntax.
But you are right that in that case I shouldn't have used the nml namespace if it is not NML.
What do you suggest?
I would not use nml namespace if the elements don't apply NML schema. Simply, I would remove it from your examples.
I can understand the desire to make it a short piece of NML, but that would require introducing id/idRef, the hasInboundPort/hasOutboundPort relations, hence the nml:Relation construct. The original proposal used query parts in the URN, which is not part of NML (I'm not even sure if the query part is part of the URN or not -- see my mail http://www.ogf.org/pipermail/nml-wg/2012-July/001012.html).
I like Aaron proposal to use child elements and keep URN identifiers/strings static.
A further complication was that the NSI in some case want to define a Port or subset of the PortGroup within a larger PortGroup by identifying it by its label or label subset, without actually naming the result. That would require me to introduce unnamed NML objects (NML objects without a URN identifier, that are identified by their properties). I may want to do that anyway, but felt this was a bit too much wrestling if all I wanted was a reference.
Do we really need to have such unnamed NML objects? Maybe some query syntax used by NSI would represent the groups filtered from NML topologies (clear distinction: NML gives topology data, applications parse/fetch/filter that data the way they need). Roman
But by all means rewrite the examples and propose it to NML + NSI. To me this is not NML, but you have a valid argument that if this is just syntactic sugar to define a reference, why not make the sugar look like the same.
Regards, Freek
On 11-07-2012 16:39, Roman Łapacz wrote:
What do you suggest?
I would not use nml namespace if the elements don't apply NML schema. Simply, I would remove it from your examples.
OK, I got the same feedback in the NSI conference call today. I will remove it and leave it up to the NSI-WG what namespace to use, but will make it clear that "Port", "PortGroup" and "label" are NML constructs. I'm going to update my proposal to the NSI-WG. What should I use: Unless you have a strong preference, I'm going to use:
<sink> <PortGroup>urn:ogf:network:nordu.net:2012:surfnet-nordunet</PortGroup> <labelgroup labeltype="http://schemas.ogf.org/nml/2013/10/ethernet/vlan">1800-1899</labelgroup> </sink>
Instead of:
<sink> <PortGroup idRef="urn:ogf:network:nordu.net:2012:surfnet-nordunet"/> <labelgroup labeltype="http://schemas.ogf.org/nml/2013/10/ethernet/vlan">1800-1899</labelgroup> </sink>
(The reason is that I didn't bother to introduce NML constructs in the NSI. In short, I really want to to REFER to NML, but I don't want them to BE NML. However, if you really think I should introduce idRef to NSI, this is a good time.).
I can understand the desire to make it a short piece of NML, but that would require introducing id/idRef, the hasInboundPort/hasOutboundPort relations, hence the nml:Relation construct. The original proposal used query parts in the URN, which is not part of NML (I'm not even sure if the query part is part of the URN or not -- see my mail http://www.ogf.org/pipermail/nml-wg/2012-July/001012.html).
I like Aaron proposal to use child elements and keep URN identifiers/strings static.
For those not on the NSI list, Aaron's proposal is here: http://www.ogf.org/pipermail/nsi-wg/2012-July/001984.html And my proposal to the NSI-WG is here: http://www.ogf.org/pipermail/nsi-wg/2012-July/001993.html I tried to base my proposal on Aaron's examples, with the child element for labels. (Although I did change some of the names, and made the label syntax a bit more generic to support non-VLAN labels). Consider this the (over)due credit to Aaron for helping get this work going. Freek
W dniu 2012-07-11 17:20, Freek Dijkstra pisze:
On 11-07-2012 16:39, Roman Łapacz wrote:
What do you suggest? I would not use nml namespace if the elements don't apply NML schema. Simply, I would remove it from your examples. OK, I got the same feedback in the NSI conference call today. I will remove it and leave it up to the NSI-WG what namespace to use, but will make it clear that "Port", "PortGroup" and "label" are NML constructs.
I'm going to update my proposal to the NSI-WG. What should I use:
Unless you have a strong preference, I'm going to use:
<sink> <PortGroup>urn:ogf:network:nordu.net:2012:surfnet-nordunet</PortGroup> <labelgroup labeltype="http://schemas.ogf.org/nml/2013/10/ethernet/vlan">1800-1899</labelgroup> </sink> Instead of:
<sink> <PortGroup idRef="urn:ogf:network:nordu.net:2012:surfnet-nordunet"/> <labelgroup labeltype="http://schemas.ogf.org/nml/2013/10/ethernet/vlan">1800-1899</labelgroup> </sink>
If it's not NML then the first proposal above seems to be better as I haven't seen the idRef attribute concept in NSI examples. Use of IdRef (as it is in the second example) may raise a question what's for. In case of NML/NMC/NM the response is obvious, for NSI probably not. But to be honest if NSI files include topology information it would be ideally if NML proper constructs (nml namespace) were used for that. That is why xml namespaces exist to reuse existing solutions. Roman
(The reason is that I didn't bother to introduce NML constructs in the NSI. In short, I really want to to REFER to NML, but I don't want them to BE NML. However, if you really think I should introduce idRef to NSI, this is a good time.).
I can understand the desire to make it a short piece of NML, but that would require introducing id/idRef, the hasInboundPort/hasOutboundPort relations, hence the nml:Relation construct. The original proposal used query parts in the URN, which is not part of NML (I'm not even sure if the query part is part of the URN or not -- see my mail http://www.ogf.org/pipermail/nml-wg/2012-July/001012.html). I like Aaron proposal to use child elements and keep URN identifiers/strings static. For those not on the NSI list, Aaron's proposal is here: http://www.ogf.org/pipermail/nsi-wg/2012-July/001984.html And my proposal to the NSI-WG is here: http://www.ogf.org/pipermail/nsi-wg/2012-July/001993.html
I tried to base my proposal on Aaron's examples, with the child element for labels. (Although I did change some of the names, and made the label syntax a bit more generic to support non-VLAN labels).
Consider this the (over)due credit to Aaron for helping get this work going.
Freek
Do you have a formalized schema defined for the NML namespace we can compile? I have only ever seen XML snippets. To help solidify the NSI 2.0 WSDL contract I would like to reference a concrete fixed namespace, otherwise, I will need to leave it open ended and that would lead to compatibility issues. Thanks, John. On 2012-07-11, at 11:20 AM, Freek Dijkstra wrote:
On 11-07-2012 16:39, Roman Łapacz wrote:
What do you suggest?
I would not use nml namespace if the elements don't apply NML schema. Simply, I would remove it from your examples.
OK, I got the same feedback in the NSI conference call today. I will remove it and leave it up to the NSI-WG what namespace to use, but will make it clear that "Port", "PortGroup" and "label" are NML constructs.
I'm going to update my proposal to the NSI-WG. What should I use:
Unless you have a strong preference, I'm going to use:
<sink> <PortGroup>urn:ogf:network:nordu.net:2012:surfnet-nordunet</PortGroup> <labelgroup labeltype="http://schemas.ogf.org/nml/2013/10/ethernet/vlan">1800-1899</labelgroup> </sink>
Instead of:
<sink> <PortGroup idRef="urn:ogf:network:nordu.net:2012:surfnet-nordunet"/> <labelgroup labeltype="http://schemas.ogf.org/nml/2013/10/ethernet/vlan">1800-1899</labelgroup> </sink>
(The reason is that I didn't bother to introduce NML constructs in the NSI. In short, I really want to to REFER to NML, but I don't want them to BE NML. However, if you really think I should introduce idRef to NSI, this is a good time.).
I can understand the desire to make it a short piece of NML, but that would require introducing id/idRef, the hasInboundPort/hasOutboundPort relations, hence the nml:Relation construct. The original proposal used query parts in the URN, which is not part of NML (I'm not even sure if the query part is part of the URN or not -- see my mail http://www.ogf.org/pipermail/nml-wg/2012-July/001012.html).
I like Aaron proposal to use child elements and keep URN identifiers/strings static.
For those not on the NSI list, Aaron's proposal is here: http://www.ogf.org/pipermail/nsi-wg/2012-July/001984.html And my proposal to the NSI-WG is here: http://www.ogf.org/pipermail/nsi-wg/2012-July/001993.html
I tried to base my proposal on Aaron's examples, with the child element for labels. (Although I did change some of the names, and made the label syntax a bit more generic to support non-VLAN labels).
Consider this the (over)due credit to Aaron for helping get this work going.
Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
On 13-07-2012 03:27, John MacAuley wrote:
Do you have a formalized schema defined for the NML namespace we can compile? I have only ever seen XML snippets. To help solidify the NSI 2.0 WSDL contract I would like to reference a concrete fixed namespace, otherwise, I will need to leave it open ended and that would lead to compatibility issues.
Jeroen is working on a OWL schema, and Roman has created a RNC schema and had some updates later. It's on https://forge.ogf.org/svn/repos/nml-base/schemas/ but I see that Jeroen created an update just a week ago which is not yet comitted. However, both are yet untested, and should be considered first drafts with a certainty of flaws. We actually have a deadline shortly for a preliminary schema. Not sure if we make that, but at least it's on the agenda. I'd be sure to let Jeroen and Roman know that you like to volunteer to test the schema ;) A question to you -- what do you prefer, RNC or XSD for the XML schema? Freek
W dniu 2012-07-13 11:22, Freek Dijkstra pisze:
On 13-07-2012 03:27, John MacAuley wrote:
Do you have a formalized schema defined for the NML namespace we can compile? I have only ever seen XML snippets. To help solidify the NSI 2.0 WSDL contract I would like to reference a concrete fixed namespace, otherwise, I will need to leave it open ended and that would lead to compatibility issues. Jeroen is working on a OWL schema, and Roman has created a RNC schema and had some updates later.
It's on https://forge.ogf.org/svn/repos/nml-base/schemas/ but I see that Jeroen created an update just a week ago which is not yet comitted.
However, both are yet untested, and should be considered first drafts with a certainty of flaws. We actually have a deadline shortly for a preliminary schema. Not sure if we make that, but at least it's on the agenda.
I'd be sure to let Jeroen and Roman know that you like to volunteer to test the schema ;)
A question to you -- what do you prefer, RNC or XSD for the XML schema?
Next week I'll update the RNC schema. Also I'll start working on the xsd version (conversion rnc->xsd is possible but not perfect). Roman
Freek
W dniu 2012-07-13 12:59, Roman Łapacz pisze:
W dniu 2012-07-13 11:22, Freek Dijkstra pisze:
On 13-07-2012 03:27, John MacAuley wrote:
Do you have a formalized schema defined for the NML namespace we can compile? I have only ever seen XML snippets. To help solidify the NSI 2.0 WSDL contract I would like to reference a concrete fixed namespace, otherwise, I will need to leave it open ended and that would lead to compatibility issues. Jeroen is working on a OWL schema, and Roman has created a RNC schema and had some updates later.
It's on https://forge.ogf.org/svn/repos/nml-base/schemas/ but I see that Jeroen created an update just a week ago which is not yet comitted.
However, both are yet untested, and should be considered first drafts with a certainty of flaws. We actually have a deadline shortly for a preliminary schema. Not sure if we make that, but at least it's on the agenda.
I'd be sure to let Jeroen and Roman know that you like to volunteer to test the schema ;)
A question to you -- what do you prefer, RNC or XSD for the XML schema?
Next week I'll update the RNC schema. Also I'll start working on the xsd version (conversion rnc->xsd is possible but not perfect).
Updated RNC file available in the svn repo (https://forge.ogf.org/svn/repos/nml-base/schemas/) Roman
participants (3)
-
Freek Dijkstra -
John MacAuley -
Roman Łapacz