Peoples. I thought I would point out the master.xml on github is invalid NML and will not parse using the nmlbase.xml and nsi-ext.xsd schemas as defined. The nsi:isReference attribute is not defined in schema, and therefore, cannot be parsed by JAXB based off the nmlbase.xml and nsi-ext.xsd schemas. There are two problems with the XML as defined: 1. There is no anyAttribute defined in the context of the Topology element from nmlbase.xml so attributes from an external namespace cannot be included. 2. There is no isReference attribute defined in nsi-ext.xsd so it cannot be used. If we intend to use this mechanism for an extended period of time I would suggest we formalize the required schema changes as part of topology distribution version 1.0. I attached what I modified to get my implementation to work correctly. These are backward compatible changes in NML, which will allow an application compiled with the new schema to read old files, however, the reverse is not true. We should probably do an update to the standard schema once we agree on how Service Definitions get supported. John
I almost forgot the most important part - I think the contents of the master.xml is actually incorrect. We are basing everything off of topology identifiers in the current master.xml when we should be basing it off of NSA identifiers. I know the NSA I have configured and I want to read it's topology to see associated networks. At the moment I have to read all the topologies before I can find the one that corresponds to the NSA. Also, the NSA is the root element of our topology file and we should be able to have multiple topologies in a single NSA element. Based on this, we would want to turn things around a bit, and perhaps define a new master.xml schema capturing what we need. Actually, what the master.xml file should contain is the list of discovery interface for all NSA that would allow us to bootstrap the network. John On 2013-10-29, at 2:03 PM, John MacAuley <john.macauley@surfnet.nl> wrote:
Peoples.
I thought I would point out the master.xml on github is invalid NML and will not parse using the nmlbase.xml and nsi-ext.xsd schemas as defined. The nsi:isReference attribute is not defined in schema, and therefore, cannot be parsed by JAXB based off the nmlbase.xml and nsi-ext.xsd schemas.
There are two problems with the XML as defined:
1. There is no anyAttribute defined in the context of the Topology element from nmlbase.xml so attributes from an external namespace cannot be included.
2. There is no isReference attribute defined in nsi-ext.xsd so it cannot be used.
If we intend to use this mechanism for an extended period of time I would suggest we formalize the required schema changes as part of topology distribution version 1.0.
I attached what I modified to get my implementation to work correctly. These are backward compatible changes in NML, which will allow an application compiled with the new schema to read old files, however, the reverse is not true. We should probably do an update to the standard schema once we agree on how Service Definitions get supported.
John
<nsi-ext.xsd> <nmlbase.xsd> _______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
On Tue, 29 Oct 2013, John MacAuley wrote:
I almost forgot the most important part - I think the contents of the master.xml is actually incorrect. We are basing everything off of topology identifiers in the current master.xml when we should be basing it off of NSA identifiers.
NSA id is definitely better than topology id here. But do we really need any of the ids? The NSA id is contained in the document.
Also, the NSA is the root element of our topology file and we should be able to have multiple topologies in a single NSA element.
Did you read the security stuff I wrote (it does not exlucde this option, but there are some limitations except if come up with an alternative security model - and we really need one).
Actually, what the master.xml file should contain is the list of discovery interface for all NSA that would allow us to bootstrap the network.
But we already have a discovery service :-). Our current topology service is really a discovery service with a topology crammed inside it. But could we focus on getting a proper topology model first. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi, On 29 Oct 2013, at 19:03, John MacAuley <john.macauley@surfnet.nl> wrote:
I thought I would point out the master.xml on github is invalid NML and will not parse using the nmlbase.xml and nsi-ext.xsd schemas as defined. The nsi:isReference attribute is not defined in schema, and therefore, cannot be parsed by JAXB based off the nmlbase.xml and nsi-ext.xsd schemas.
I know. I have been raising this issue before in both the NSI and NML group. The problem is that I do not know a way of including the nsi:isReference attribute in the NSI schema. I’ve asked how, but nobody seems to know.
There are two problems with the XML as defined:
1. There is no anyAttribute defined in the context of the Topology element from nmlbase.xml so attributes from an external namespace cannot be included.
If this is the case, then this seems to me to be a very valid change that we should try to get into the schema ASAP.
2. There is no isReference attribute defined in nsi-ext.xsd so it cannot be used.
See above. There is no way to define it in XML Schema AFAICT.
If we intend to use this mechanism for an extended period of time I would suggest we formalize the required schema changes as part of topology distribution version 1.0.
I attached what I modified to get my implementation to work correctly. These are backward compatible changes in NML, which will allow an application compiled with the new schema to read old files, however, the reverse is not true. We should probably do an update to the standard schema once we agree on how Service Definitions get supported.
I completely agree though that this would be a stop-gap solution and that we should move to some kind of Topology Service discoverable through the NSI Discovery service. At some point though we will have to have some kind of XML representation to describe the binding between a Topology and a URL. Jeroen.
participants (3)
-
Henrik Thostrup Jensen
-
Jeroen van der Ham
-
John MacAuley