Hi It seems we need a rehash of NML XML schema for support NSI. Here are some further suggestions for how to improve the schema. The changes should not change the semantics of NML, but just make it easier to parse. * Any element in PortGroup This is the main problem. John already has a fix for this. Should probably go through the NML schema and check that it is on everywhere. * Bidirectional ports after unidirectional ports In the current model a bidirectional port is composed of two unidirectional ports. When building a datastructure representation, this means that one has to construct a temporary value/object to track this mapping, as the data structure representing the undirectional ports have not yet been created. Having the bidirectional ports after the unidirectional removes this need, making the parsing simpler. * Replace nml:Relation The nml:Relation constructs are not very "XML". I suggest that instead of <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> one would use: <nml:InboundPorts> Several elements would have to be constructed for this though. * Identical List constructs The way list of bidirectional ports and unidirectional ports are created are different. Bidirectional ports are repeated in the topology element, where as unidirectional ports are contained under an element. I.e: <nml:Topology id=...> <nml:BidirectionalPort id=...> ... </nml:BidirectionalPort> <nml:BidirectionalPort id=...> ... </nml:BidirectionalPort> <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> <nml:PortGroup id=...> ... </nml:PortGroup> <nml:PortGroup id=...> ... </nml:PortGroup> </nml:Relation> </nml:Topology> There isn't really a wrong or right way to do this, but I think doing both is the worst option. I understand that bidirectional ports are a somewhat special things in NML, but they could still easily be contained in an element. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Further suggestions: Relax the ORGID constraint to be FQDN only, as (AFAICT) there is no practical way of enforcing the DATE part. Add labelType attribute in switching service to indicate which labels can be switched (this one has already been discussed, this is just to add it to the list). /Henrik On Thu, 7 Nov 2013, Henrik Thostrup Jensen wrote:
Hi
It seems we need a rehash of NML XML schema for support NSI. Here are some further suggestions for how to improve the schema. The changes should not change the semantics of NML, but just make it easier to parse.
* Any element in PortGroup
This is the main problem. John already has a fix for this. Should probably go through the NML schema and check that it is on everywhere.
* Bidirectional ports after unidirectional ports
In the current model a bidirectional port is composed of two unidirectional ports. When building a datastructure representation, this means that one has to construct a temporary value/object to track this mapping, as the data structure representing the undirectional ports have not yet been created. Having the bidirectional ports after the unidirectional removes this need, making the parsing simpler.
* Replace nml:Relation
The nml:Relation constructs are not very "XML". I suggest that instead of <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> one would use: <nml:InboundPorts> Several elements would have to be constructed for this though.
* Identical List constructs
The way list of bidirectional ports and unidirectional ports are created are different. Bidirectional ports are repeated in the topology element, where as unidirectional ports are contained under an element. I.e:
<nml:Topology id=...> <nml:BidirectionalPort id=...> ... </nml:BidirectionalPort> <nml:BidirectionalPort id=...> ... </nml:BidirectionalPort>
<nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> <nml:PortGroup id=...> ... </nml:PortGroup> <nml:PortGroup id=...> ... </nml:PortGroup> </nml:Relation> </nml:Topology>
There isn't really a wrong or right way to do this, but I think doing both is the worst option. I understand that bidirectional ports are a somewhat special things in NML, but they could still easily be contained in an element.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Hi, Just to make it clear: I have been the editor of the NML base schema document and in that role flogged you all into action. That document is now published. Furthermore, I’ve taken a new job where I do not have much time to dedicate to this. So I will not be able to take action, or push others to take action. That being said, I completely agree with the points below, and would welcome an update, errata, or addendum (whichever form is appropriate in the OGF context). Jeroen. On 7 Nov 2013, at 13:35, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi
It seems we need a rehash of NML XML schema for support NSI. Here are some further suggestions for how to improve the schema. The changes should not change the semantics of NML, but just make it easier to parse.
* Any element in PortGroup
This is the main problem. John already has a fix for this. Should probably go through the NML schema and check that it is on everywhere.
* Bidirectional ports after unidirectional ports
In the current model a bidirectional port is composed of two unidirectional ports. When building a datastructure representation, this means that one has to construct a temporary value/object to track this mapping, as the data structure representing the undirectional ports have not yet been created. Having the bidirectional ports after the unidirectional removes this need, making the parsing simpler.
* Replace nml:Relation
The nml:Relation constructs are not very "XML". I suggest that instead of <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> one would use: <nml:InboundPorts> Several elements would have to be constructed for this though.
* Identical List constructs
The way list of bidirectional ports and unidirectional ports are created are different. Bidirectional ports are repeated in the topology element, where as unidirectional ports are contained under an element. I.e:
<nml:Topology id=...> <nml:BidirectionalPort id=...> ... </nml:BidirectionalPort> <nml:BidirectionalPort id=...> ... </nml:BidirectionalPort>
<nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> <nml:PortGroup id=...> ... </nml:PortGroup> <nml:PortGroup id=...> ... </nml:PortGroup> </nml:Relation> </nml:Topology>
There isn't really a wrong or right way to do this, but I think doing both is the worst option. I understand that bidirectional ports are a somewhat special things in NML, but they could still easily be contained in an element.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
Don't worry Jeroen. Now that you have users there will be tons issues popping up that you can not take action on ;-) On 2013-11-12, at 5:50 AM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hi,
Just to make it clear: I have been the editor of the NML base schema document and in that role flogged you all into action. That document is now published. Furthermore, I’ve taken a new job where I do not have much time to dedicate to this. So I will not be able to take action, or push others to take action.
That being said, I completely agree with the points below, and would welcome an update, errata, or addendum (whichever form is appropriate in the OGF context).
Jeroen.
On 7 Nov 2013, at 13:35, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Hi
It seems we need a rehash of NML XML schema for support NSI. Here are some further suggestions for how to improve the schema. The changes should not change the semantics of NML, but just make it easier to parse.
* Any element in PortGroup
This is the main problem. John already has a fix for this. Should probably go through the NML schema and check that it is on everywhere.
* Bidirectional ports after unidirectional ports
In the current model a bidirectional port is composed of two unidirectional ports. When building a datastructure representation, this means that one has to construct a temporary value/object to track this mapping, as the data structure representing the undirectional ports have not yet been created. Having the bidirectional ports after the unidirectional removes this need, making the parsing simpler.
* Replace nml:Relation
The nml:Relation constructs are not very "XML". I suggest that instead of <nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> one would use: <nml:InboundPorts> Several elements would have to be constructed for this though.
* Identical List constructs
The way list of bidirectional ports and unidirectional ports are created are different. Bidirectional ports are repeated in the topology element, where as unidirectional ports are contained under an element. I.e:
<nml:Topology id=...> <nml:BidirectionalPort id=...> ... </nml:BidirectionalPort> <nml:BidirectionalPort id=...> ... </nml:BidirectionalPort>
<nml:Relation type="http://schemas.ogf.org/nml/2013/05/base#hasInboundPort"> <nml:PortGroup id=...> ... </nml:PortGroup> <nml:PortGroup id=...> ... </nml:PortGroup> </nml:Relation> </nml:Topology>
There isn't really a wrong or right way to do this, but I think doing both is the worst option. I understand that bidirectional ports are a somewhat special things in NML, but they could still easily be contained in an element.
Best regards, Henrik
Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
participants (3)
-
Henrik Thostrup Jensen -
Jeroen van der Ham -
John MacAuley