Hello all, It is with great trepidation that I present to you a draft of the "Network Markup Language Base Schema version 1". Please have a look through it and let us/me know what you think about this document. With the feedback we get, we will improve the document and we plan to finally start the process on this document next month. Thanks! Jeroen.
Hi Jeroen/All; Please find attached my review/comments on the NML base document. All in all an excellent effort and we are nearly there. Thanks; -jason On Oct 11, 2012, at 3:25 PM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hello all,
It is with great trepidation that I present to you a draft of the "Network Markup Language Base Schema version 1".
Please have a look through it and let us/me know what you think about this document.
With the feedback we get, we will improve the document and we plan to finally start the process on this document next month.
Thanks! Jeroen.
<nml-base.pdf>_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Jason, Thanks a lot for your review! You made a lot of good suggestions. Jeroen was just poking me off-list about adding a few examples to the descriptions, in particular for Adaptation and for Labels. So far my take has been to not include examples there, but include them in the Examples chapter instead. The reason is twofold: first of all, the descriptions are normative, the example informative. Secondly, there is a bit more room for text in the Examples chapter. I usually never understand a new concept until I have seen TWO examples. Only then, the general pattern starts to dawn on me. So I prefer two examples per definition. That said --- I just hope that Jeroen does whatever makes the document more readable. If adding examples makes it easier to read and implement, I support that. For the record, here is a list of examples I still like to include in the Examples chapter, because they don't seem obvious to me at first: * distinction between Topology and Node * VLAN description with noReturnTraffic * subTopology * patch panel * media convertor * adaptation * serial compound links (and importance to use directions) * example explaining the relation between version and Lifetime. Imagine that a link will have a planned downtime next week between 2 AM and 4 AM, but I now know it will be between 2 AM and 5 AM. Explain how to update this information. * Add example, explaining how to distinguish between what is configured and what can be configured. Regards, Freek
Hi, I'm trying to go through all of your comments. Most are very sensible and I'll apply the changes as suggested. The new version is at: https://forge.ogf.org/sf/docman/do/downloadDocument/projects.nml-wg/docman.r... For other changes that I have not (yet) included, comments are below: - Abstract "computer networks" -- the idea of Paola's GreenSonar talk (and other things we are trying to do) is that we combine descriptions using different ontologies. So yes, it makes sense that we broaden the scope, but I feel that NML should focus on computer networks. - Introduction "sub-classed" -- in some way it does map to an OO context, but slightly different, which is to be expected in this different context. It is explained in more detail in the doc and in the examples, so I'm proposing to keep it like this. - Schema unidirectionality -- the Port object itself does not define direction, but the relations to that Port (hasInboundPort / hasOutboundPort) do define a direction. - Schema "Label" -- the Label is an object which is described later (just like other objects referred to), so I'm proposing to keep it like this. - Schema "isSerialCompoundLink" -- New blurb added to the Link text: A \emph{Link} object can have a \emph{isSerialCompoundLink} relation to a \emph{List} of \emph{Links}. This describes that the \emph{Link} represents a path through the network implemented by that (ordered) \emph{List} of \emph{Links}. - Schema Service -- We don't explicitly mention extension possibilities for other objects, should we really mention it explicitly for the Service object? - Schema Relation -- The table is a nice idea, but in practice I think it would take up too much space, and would double much information. You would have four columns: the name, the domain, range and definition of the relation: for example: existsDuring | Network Object | LifeTime | relates a LifeTime object to a Network Object It really becomes quite wide, and for most would not fit on a single line anymore. -- Schema Extension Paragraph-- Very good suggestion, I'll add something on this soon. -- Identifiers interpreting -- I would love to include something to describe why you should not be interpreting identifiers, but I don't know a succint way of doing that. Does anyone have a good idea? -- Informative References -- I looked up the article you suggested to add. It mostly describes the NMWG format. Is that still relevant? If so, a paper on NDL would similarly be relevant, and I could add some other papers from other projects too. -- Acknowledgements -- I think it's proper to add financial support from different projects, should we do that on a personal or general level? (I have to add grant numbers also). Jeroen. On 4 Nov 2012, at 21:09, Jason Zurawski <zurawski@internet2.edu> wrote:
Hi Jeroen/All;
Please find attached my review/comments on the NML base document. All in all an excellent effort and we are nearly there.
Thanks;
-jason
<20121104-nml-base-jz.pdf> On Oct 11, 2012, at 3:25 PM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hello all,
It is with great trepidation that I present to you a draft of the "Network Markup Language Base Schema version 1".
Please have a look through it and let us/me know what you think about this document.
With the feedback we get, we will improve the document and we plan to finally start the process on this document next month.
Thanks! Jeroen.
<nml-base.pdf>_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Since I was reminded (by you! :)) that I never commented - here are my comments: all of this is fine with me. Proceed at full throttle. -jason On Nov 6, 2012, at 8:42 AM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hi,
I'm trying to go through all of your comments. Most are very sensible and I'll apply the changes as suggested. The new version is at: https://forge.ogf.org/sf/docman/do/downloadDocument/projects.nml-wg/docman.r...
For other changes that I have not (yet) included, comments are below:
- Abstract "computer networks" -- the idea of Paola's GreenSonar talk (and other things we are trying to do) is that we combine descriptions using different ontologies. So yes, it makes sense that we broaden the scope, but I feel that NML should focus on computer networks.
- Introduction "sub-classed" -- in some way it does map to an OO context, but slightly different, which is to be expected in this different context. It is explained in more detail in the doc and in the examples, so I'm proposing to keep it like this.
- Schema unidirectionality -- the Port object itself does not define direction, but the relations to that Port (hasInboundPort / hasOutboundPort) do define a direction.
- Schema "Label" -- the Label is an object which is described later (just like other objects referred to), so I'm proposing to keep it like this.
- Schema "isSerialCompoundLink" -- New blurb added to the Link text: A \emph{Link} object can have a \emph{isSerialCompoundLink} relation to a \emph{List} of \emph{Links}. This describes that the \emph{Link} represents a path through the network implemented by that (ordered) \emph{List} of \emph{Links}.
- Schema Service -- We don't explicitly mention extension possibilities for other objects, should we really mention it explicitly for the Service object?
- Schema Relation -- The table is a nice idea, but in practice I think it would take up too much space, and would double much information. You would have four columns: the name, the domain, range and definition of the relation: for example:
existsDuring | Network Object | LifeTime | relates a LifeTime object to a Network Object
It really becomes quite wide, and for most would not fit on a single line anymore.
-- Schema Extension Paragraph-- Very good suggestion, I'll add something on this soon.
-- Identifiers interpreting -- I would love to include something to describe why you should not be interpreting identifiers, but I don't know a succint way of doing that. Does anyone have a good idea?
-- Informative References -- I looked up the article you suggested to add. It mostly describes the NMWG format. Is that still relevant? If so, a paper on NDL would similarly be relevant, and I could add some other papers from other projects too.
-- Acknowledgements -- I think it's proper to add financial support from different projects, should we do that on a personal or general level? (I have to add grant numbers also).
Jeroen.
On 4 Nov 2012, at 21:09, Jason Zurawski <zurawski@internet2.edu> wrote:
Hi Jeroen/All;
Please find attached my review/comments on the NML base document. All in all an excellent effort and we are nearly there.
Thanks;
-jason
<20121104-nml-base-jz.pdf> On Oct 11, 2012, at 3:25 PM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hello all,
It is with great trepidation that I present to you a draft of the "Network Markup Language Base Schema version 1".
Please have a look through it and let us/me know what you think about this document.
With the feedback we get, we will improve the document and we plan to finally start the process on this document next month.
Thanks! Jeroen.
<nml-base.pdf>_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
----- Jason Zurawski, Senior Research Engineer Internet2 zurawski@internet2.edu office: [+1-202-331-5354] mobile: [+1-703-981-2494] fax: [+1-202-872-4318] TIP2013, University of Hawaii Mānoa January 13 - January 17, 2013, Honolulu, HI http://events.internet2.edu/2013/tip/
Jeroen, Given how disenchanted I am with OWL at the moment I thought I would have a look at your schema and maybe use it to directly process the A-GOLE topology. I thought I would capture the compile errors I am getting before going into any comments on the specific schema. 1. TopologyType - Your loose definition in BaseTopologyContent using <xs:any minOccurs="0"/> causes a possible conflict with the current namespace since you can include the same object and get name conflicts. Is this what you intended or are you looking to include from other namespaces? If you change the definitions to <xs:any namespace="##other" processContents="lax" minOccurs="0" /> it fixes the issue, but may not be what you want. Error [Xerces] cos-nonambig: "http://schemas.ogf.org/nml/2012/10/base#":name and WC[##any] (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles. <xs:group name="BaseTopologyContent"> <xs:sequence> <xs:element ref="nml:Link" minOccurs="0"/> <xs:element ref="nml:Port" minOccurs="0"/> <xs:element ref="nml:Node" minOccurs="0"/> <xs:group ref="nml:Service" minOccurs="0"/> <xs:group ref="nml:Group" minOccurs="0"/> <xs:any minOccurs="0"/> </xs:sequence> </xs:group> 2. LinkType - multiple elements in Label named Label. Error [Xerces] cos-element-consistent: Error for type 'LinkType'. Multiple elements with name 'Label', with different types, appear in the model group. <xs:group name="Label"> <xs:choice> <xs:element name="Label" type="nml:LabelType"/> <xs:element name="Label" type="nml:LabelAttrType"/> <xs:element name="Label" type="nml:LabelExtType"/> </xs:choice> </xs:group> 3. PortType - Same as above - multiple elements in Label named Label and name ambiguity. The <xs:any minOccurs="0"/> in BasePortContent. Error [Xerces] cos-element-consistent: Error for type 'PortType'. Multiple elements with name 'Label', with different types, appear in the model group. Error [Xerces] cos-nonambig: "http://schemas.ogf.org/nml/2012/10/base#":name and WC[##any] (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles. 4. NodeType - The <xs:any minOccurs="0"/> in BaseLinkContent. Error [Xerces] cos-nonambig: "http://schemas.ogf.org/nml/2012/10/base#":name and WC[##any] (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles. <xs:group name="BaseLinkContent"> <xs:sequence> <xs:group ref="nml:Label" minOccurs="0"/> <xs:any minOccurs="0"/> </xs:sequence> </xs:group> 5. LinkGroupType - Multiple elements in LabelGroup named LabelGroup. Error [Xerces] cos-nonambig: "http://schemas.ogf.org/nml/2012/10/base#":LabelGroup and "http://schemas.ogf.org/nml/2012/10/base#":LabelGroup (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles. <xs:group name="LabelGroup"> <xs:choice> <xs:element name="LabelGroup" type="nml:LabelGroupType"/> <xs:element name="LabelGroup" type="nml:LabelGroupAttrType"/> <xs:element name="LabelGroup" type="nml:LabelGroupExtType"/> </xs:choice> </xs:group> Looks like you have three elements named LabelGroup. 6. PortGroupType - - Multiple elements in LabelGroup named LabelGroup. Error [Xerces] cos-nonambig: "http://schemas.ogf.org/nml/2012/10/base#":LabelGroup and "http://schemas.ogf.org/nml/2012/10/base#":LabelGroup (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles. John ----- Original Message -----
From: "Jason Zurawski" <zurawski@internet2.edu> To: "Jeroen van der Ham" <vdham@uva.nl> Cc: "<nml-wg@ogf.org> Working Group" <nml-wg@ogf.org> Sent: Saturday, November 10, 2012 7:33:00 PM Subject: Re: [Nml-wg] First draft of NML Schema document
Since I was reminded (by you! :)) that I never commented - here are my comments: all of this is fine with me. Proceed at full throttle.
-jason
On Nov 6, 2012, at 8:42 AM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hi,
I'm trying to go through all of your comments. Most are very sensible and I'll apply the changes as suggested. The new version is at: https://forge.ogf.org/sf/docman/do/downloadDocument/projects.nml-wg/docman.r...
For other changes that I have not (yet) included, comments are below:
- Abstract "computer networks" -- the idea of Paola's GreenSonar talk (and other things we are trying to do) is that we combine descriptions using different ontologies. So yes, it makes sense that we broaden the scope, but I feel that NML should focus on computer networks.
- Introduction "sub-classed" -- in some way it does map to an OO context, but slightly different, which is to be expected in this different context. It is explained in more detail in the doc and in the examples, so I'm proposing to keep it like this.
- Schema unidirectionality -- the Port object itself does not define direction, but the relations to that Port (hasInboundPort / hasOutboundPort) do define a direction.
- Schema "Label" -- the Label is an object which is described later (just like other objects referred to), so I'm proposing to keep it like this.
- Schema "isSerialCompoundLink" -- New blurb added to the Link text: A \emph{Link} object can have a \emph{isSerialCompoundLink} relation to a \emph{List} of \emph{Links}. This describes that the \emph{Link} represents a path through the network implemented by that (ordered) \emph{List} of \emph{Links}.
- Schema Service -- We don't explicitly mention extension possibilities for other objects, should we really mention it explicitly for the Service object?
- Schema Relation -- The table is a nice idea, but in practice I think it would take up too much space, and would double much information. You would have four columns: the name, the domain, range and definition of the relation: for example:
existsDuring | Network Object | LifeTime | relates a LifeTime object to a Network Object
It really becomes quite wide, and for most would not fit on a single line anymore.
-- Schema Extension Paragraph-- Very good suggestion, I'll add something on this soon.
-- Identifiers interpreting -- I would love to include something to describe why you should not be interpreting identifiers, but I don't know a succint way of doing that. Does anyone have a good idea?
-- Informative References -- I looked up the article you suggested to add. It mostly describes the NMWG format. Is that still relevant? If so, a paper on NDL would similarly be relevant, and I could add some other papers from other projects too.
-- Acknowledgements -- I think it's proper to add financial support from different projects, should we do that on a personal or general level? (I have to add grant numbers also).
Jeroen.
On 4 Nov 2012, at 21:09, Jason Zurawski <zurawski@internet2.edu> wrote:
Hi Jeroen/All;
Please find attached my review/comments on the NML base document. All in all an excellent effort and we are nearly there.
Thanks;
-jason
<20121104-nml-base-jz.pdf> On Oct 11, 2012, at 3:25 PM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hello all,
It is with great trepidation that I present to you a draft of the "Network Markup Language Base Schema version 1".
Please have a look through it and let us/me know what you think about this document.
With the feedback we get, we will improve the document and we plan to finally start the process on this document next month.
Thanks! Jeroen.
<nml-base.pdf>_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
-----
Jason Zurawski, Senior Research Engineer Internet2 zurawski@internet2.edu office: [+1-202-331-5354] mobile: [+1-703-981-2494] fax: [+1-202-872-4318]
TIP2013, University of Hawaii Mānoa January 13 - January 17, 2013, Honolulu, HI http://events.internet2.edu/2013/tip/
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Hi John, I used Trang for validation and didn't get the errors you listed. I'll take a look at them after my travel (next week). Thanks, Roman W dniu 2012-11-13 16:40, John MacAuley pisze:
Jeroen,
Given how disenchanted I am with OWL at the moment I thought I would have a look at your schema and maybe use it to directly process the A-GOLE topology. I thought I would capture the compile errors I am getting before going into any comments on the specific schema.
1. TopologyType - Your loose definition in BaseTopologyContent using <xs:any minOccurs="0"/> causes a possible conflict with the current namespace since you can include the same object and get name conflicts. Is this what you intended or are you looking to include from other namespaces? If you change the definitions to <xs:any namespace="##other" processContents="lax" minOccurs="0" /> it fixes the issue, but may not be what you want.
Error [Xerces] cos-nonambig: "http://schemas.ogf.org/nml/2012/10/base#":name and WC[##any] (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.
<xs:group name="BaseTopologyContent"> <xs:sequence> <xs:element ref="nml:Link" minOccurs="0"/> <xs:element ref="nml:Port" minOccurs="0"/> <xs:element ref="nml:Node" minOccurs="0"/> <xs:group ref="nml:Service" minOccurs="0"/> <xs:group ref="nml:Group" minOccurs="0"/> <xs:any minOccurs="0"/> </xs:sequence> </xs:group>
2. LinkType - multiple elements in Label named Label.
Error [Xerces] cos-element-consistent: Error for type 'LinkType'. Multiple elements with name 'Label', with different types, appear in the model group.
<xs:group name="Label"> <xs:choice> <xs:element name="Label" type="nml:LabelType"/> <xs:element name="Label" type="nml:LabelAttrType"/> <xs:element name="Label" type="nml:LabelExtType"/> </xs:choice> </xs:group>
3. PortType - Same as above - multiple elements in Label named Label and name ambiguity. The <xs:any minOccurs="0"/> in BasePortContent.
Error [Xerces] cos-element-consistent: Error for type 'PortType'. Multiple elements with name 'Label', with different types, appear in the model group.
Error [Xerces] cos-nonambig: "http://schemas.ogf.org/nml/2012/10/base#":name and WC[##any] (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.
4. NodeType - The <xs:any minOccurs="0"/> in BaseLinkContent.
Error [Xerces] cos-nonambig: "http://schemas.ogf.org/nml/2012/10/base#":name and WC[##any] (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.
<xs:group name="BaseLinkContent"> <xs:sequence> <xs:group ref="nml:Label" minOccurs="0"/> <xs:any minOccurs="0"/> </xs:sequence> </xs:group>
5. LinkGroupType - Multiple elements in LabelGroup named LabelGroup.
Error [Xerces] cos-nonambig: "http://schemas.ogf.org/nml/2012/10/base#":LabelGroup and "http://schemas.ogf.org/nml/2012/10/base#":LabelGroup (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.
<xs:group name="LabelGroup"> <xs:choice> <xs:element name="LabelGroup" type="nml:LabelGroupType"/> <xs:element name="LabelGroup" type="nml:LabelGroupAttrType"/> <xs:element name="LabelGroup" type="nml:LabelGroupExtType"/> </xs:choice> </xs:group>
Looks like you have three elements named LabelGroup.
6. PortGroupType - - Multiple elements in LabelGroup named LabelGroup.
Error [Xerces] cos-nonambig: "http://schemas.ogf.org/nml/2012/10/base#":LabelGroup and "http://schemas.ogf.org/nml/2012/10/base#":LabelGroup (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.
John
----- Original Message -----
From: "Jason Zurawski" <zurawski@internet2.edu> To: "Jeroen van der Ham" <vdham@uva.nl> Cc: "<nml-wg@ogf.org> Working Group" <nml-wg@ogf.org> Sent: Saturday, November 10, 2012 7:33:00 PM Subject: Re: [Nml-wg] First draft of NML Schema document
Since I was reminded (by you! :)) that I never commented - here are my comments: all of this is fine with me. Proceed at full throttle.
-jason
On Nov 6, 2012, at 8:42 AM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hi,
I'm trying to go through all of your comments. Most are very sensible and I'll apply the changes as suggested. The new version is at: https://forge.ogf.org/sf/docman/do/downloadDocument/projects.nml-wg/docman.r...
For other changes that I have not (yet) included, comments are below:
- Abstract "computer networks" -- the idea of Paola's GreenSonar talk (and other things we are trying to do) is that we combine descriptions using different ontologies. So yes, it makes sense that we broaden the scope, but I feel that NML should focus on computer networks.
- Introduction "sub-classed" -- in some way it does map to an OO context, but slightly different, which is to be expected in this different context. It is explained in more detail in the doc and in the examples, so I'm proposing to keep it like this.
- Schema unidirectionality -- the Port object itself does not define direction, but the relations to that Port (hasInboundPort / hasOutboundPort) do define a direction.
- Schema "Label" -- the Label is an object which is described later (just like other objects referred to), so I'm proposing to keep it like this.
- Schema "isSerialCompoundLink" -- New blurb added to the Link text: A \emph{Link} object can have a \emph{isSerialCompoundLink} relation to a \emph{List} of \emph{Links}. This describes that the \emph{Link} represents a path through the network implemented by that (ordered) \emph{List} of \emph{Links}.
- Schema Service -- We don't explicitly mention extension possibilities for other objects, should we really mention it explicitly for the Service object?
- Schema Relation -- The table is a nice idea, but in practice I think it would take up too much space, and would double much information. You would have four columns: the name, the domain, range and definition of the relation: for example:
existsDuring | Network Object | LifeTime | relates a LifeTime object to a Network Object
It really becomes quite wide, and for most would not fit on a single line anymore.
-- Schema Extension Paragraph-- Very good suggestion, I'll add something on this soon.
-- Identifiers interpreting -- I would love to include something to describe why you should not be interpreting identifiers, but I don't know a succint way of doing that. Does anyone have a good idea?
-- Informative References -- I looked up the article you suggested to add. It mostly describes the NMWG format. Is that still relevant? If so, a paper on NDL would similarly be relevant, and I could add some other papers from other projects too.
-- Acknowledgements -- I think it's proper to add financial support from different projects, should we do that on a personal or general level? (I have to add grant numbers also).
Jeroen.
On 4 Nov 2012, at 21:09, Jason Zurawski <zurawski@internet2.edu> wrote:
Hi Jeroen/All;
Please find attached my review/comments on the NML base document. All in all an excellent effort and we are nearly there.
Thanks;
-jason
<20121104-nml-base-jz.pdf> On Oct 11, 2012, at 3:25 PM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hello all,
It is with great trepidation that I present to you a draft of the "Network Markup Language Base Schema version 1".
Please have a look through it and let us/me know what you think about this document.
With the feedback we get, we will improve the document and we plan to finally start the process on this document next month.
Thanks! Jeroen.
<nml-base.pdf>_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Jason Zurawski, Senior Research Engineer Internet2 zurawski@internet2.edu office: [+1-202-331-5354] mobile: [+1-703-981-2494] fax: [+1-202-872-4318]
TIP2013, University of Hawaii Mānoa January 13 - January 17, 2013, Honolulu, HI http://events.internet2.edu/2013/tip/
_______________________________________________ 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
Hi, I have updated the xsd schema (validated by StdInParse/Xcerces C++). This new version should be used in the nml base doc. Thanks John for your comments. Roman W dniu 2012-11-13 16:40, John MacAuley pisze:
Jeroen,
Given how disenchanted I am with OWL at the moment I thought I would have a look at your schema and maybe use it to directly process the A-GOLE topology. I thought I would capture the compile errors I am getting before going into any comments on the specific schema.
1. TopologyType - Your loose definition in BaseTopologyContent using <xs:any minOccurs="0"/> causes a possible conflict with the current namespace since you can include the same object and get name conflicts. Is this what you intended or are you looking to include from other namespaces? If you change the definitions to <xs:any namespace="##other" processContents="lax" minOccurs="0" /> it fixes the issue, but may not be what you want.
Error [Xerces] cos-nonambig: "http://schemas.ogf.org/nml/2012/10/base#":name and WC[##any] (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.
<xs:group name="BaseTopologyContent"> <xs:sequence> <xs:element ref="nml:Link" minOccurs="0"/> <xs:element ref="nml:Port" minOccurs="0"/> <xs:element ref="nml:Node" minOccurs="0"/> <xs:group ref="nml:Service" minOccurs="0"/> <xs:group ref="nml:Group" minOccurs="0"/> <xs:any minOccurs="0"/> </xs:sequence> </xs:group>
2. LinkType - multiple elements in Label named Label.
Error [Xerces] cos-element-consistent: Error for type 'LinkType'. Multiple elements with name 'Label', with different types, appear in the model group.
<xs:group name="Label"> <xs:choice> <xs:element name="Label" type="nml:LabelType"/> <xs:element name="Label" type="nml:LabelAttrType"/> <xs:element name="Label" type="nml:LabelExtType"/> </xs:choice> </xs:group>
3. PortType - Same as above - multiple elements in Label named Label and name ambiguity. The <xs:any minOccurs="0"/> in BasePortContent.
Error [Xerces] cos-element-consistent: Error for type 'PortType'. Multiple elements with name 'Label', with different types, appear in the model group.
Error [Xerces] cos-nonambig: "http://schemas.ogf.org/nml/2012/10/base#":name and WC[##any] (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.
4. NodeType - The <xs:any minOccurs="0"/> in BaseLinkContent.
Error [Xerces] cos-nonambig: "http://schemas.ogf.org/nml/2012/10/base#":name and WC[##any] (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.
<xs:group name="BaseLinkContent"> <xs:sequence> <xs:group ref="nml:Label" minOccurs="0"/> <xs:any minOccurs="0"/> </xs:sequence> </xs:group>
5. LinkGroupType - Multiple elements in LabelGroup named LabelGroup.
Error [Xerces] cos-nonambig: "http://schemas.ogf.org/nml/2012/10/base#":LabelGroup and "http://schemas.ogf.org/nml/2012/10/base#":LabelGroup (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.
<xs:group name="LabelGroup"> <xs:choice> <xs:element name="LabelGroup" type="nml:LabelGroupType"/> <xs:element name="LabelGroup" type="nml:LabelGroupAttrType"/> <xs:element name="LabelGroup" type="nml:LabelGroupExtType"/> </xs:choice> </xs:group>
Looks like you have three elements named LabelGroup.
6. PortGroupType - - Multiple elements in LabelGroup named LabelGroup.
Error [Xerces] cos-nonambig: "http://schemas.ogf.org/nml/2012/10/base#":LabelGroup and "http://schemas.ogf.org/nml/2012/10/base#":LabelGroup (or elements from their substitution group) violate "Unique Particle Attribution". During validation against this schema, ambiguity would be created for those two particles.
John
----- Original Message -----
From: "Jason Zurawski" <zurawski@internet2.edu> To: "Jeroen van der Ham" <vdham@uva.nl> Cc: "<nml-wg@ogf.org> Working Group" <nml-wg@ogf.org> Sent: Saturday, November 10, 2012 7:33:00 PM Subject: Re: [Nml-wg] First draft of NML Schema document
Since I was reminded (by you! :)) that I never commented - here are my comments: all of this is fine with me. Proceed at full throttle.
-jason
On Nov 6, 2012, at 8:42 AM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hi,
I'm trying to go through all of your comments. Most are very sensible and I'll apply the changes as suggested. The new version is at: https://forge.ogf.org/sf/docman/do/downloadDocument/projects.nml-wg/docman.r...
For other changes that I have not (yet) included, comments are below:
- Abstract "computer networks" -- the idea of Paola's GreenSonar talk (and other things we are trying to do) is that we combine descriptions using different ontologies. So yes, it makes sense that we broaden the scope, but I feel that NML should focus on computer networks.
- Introduction "sub-classed" -- in some way it does map to an OO context, but slightly different, which is to be expected in this different context. It is explained in more detail in the doc and in the examples, so I'm proposing to keep it like this.
- Schema unidirectionality -- the Port object itself does not define direction, but the relations to that Port (hasInboundPort / hasOutboundPort) do define a direction.
- Schema "Label" -- the Label is an object which is described later (just like other objects referred to), so I'm proposing to keep it like this.
- Schema "isSerialCompoundLink" -- New blurb added to the Link text: A \emph{Link} object can have a \emph{isSerialCompoundLink} relation to a \emph{List} of \emph{Links}. This describes that the \emph{Link} represents a path through the network implemented by that (ordered) \emph{List} of \emph{Links}.
- Schema Service -- We don't explicitly mention extension possibilities for other objects, should we really mention it explicitly for the Service object?
- Schema Relation -- The table is a nice idea, but in practice I think it would take up too much space, and would double much information. You would have four columns: the name, the domain, range and definition of the relation: for example:
existsDuring | Network Object | LifeTime | relates a LifeTime object to a Network Object
It really becomes quite wide, and for most would not fit on a single line anymore.
-- Schema Extension Paragraph-- Very good suggestion, I'll add something on this soon.
-- Identifiers interpreting -- I would love to include something to describe why you should not be interpreting identifiers, but I don't know a succint way of doing that. Does anyone have a good idea?
-- Informative References -- I looked up the article you suggested to add. It mostly describes the NMWG format. Is that still relevant? If so, a paper on NDL would similarly be relevant, and I could add some other papers from other projects too.
-- Acknowledgements -- I think it's proper to add financial support from different projects, should we do that on a personal or general level? (I have to add grant numbers also).
Jeroen.
On 4 Nov 2012, at 21:09, Jason Zurawski <zurawski@internet2.edu> wrote:
Hi Jeroen/All;
Please find attached my review/comments on the NML base document. All in all an excellent effort and we are nearly there.
Thanks;
-jason
<20121104-nml-base-jz.pdf> On Oct 11, 2012, at 3:25 PM, Jeroen van der Ham <vdham@uva.nl> wrote:
Hello all,
It is with great trepidation that I present to you a draft of the "Network Markup Language Base Schema version 1".
Please have a look through it and let us/me know what you think about this document.
With the feedback we get, we will improve the document and we plan to finally start the process on this document next month.
Thanks! Jeroen.
<nml-base.pdf>_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Jason Zurawski, Senior Research Engineer Internet2 zurawski@internet2.edu office: [+1-202-331-5354] mobile: [+1-703-981-2494] fax: [+1-202-872-4318]
TIP2013, University of Hawaii Mānoa January 13 - January 17, 2013, Honolulu, HI http://events.internet2.edu/2013/tip/
_______________________________________________ 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
Just few comments/observations: 1) 1.1. "...Finally, you will not find a definition for the terms Network or capacity in this document" RL: ...but there is a definition (or piece of information) of Network object in 2.1.1. This might be misleading for a reader. 2) 2.1.1. "...The meaning of the version attribute is only defined for specific cases (in objects of the Topology class), and should not be used in other objects. Clients that receive a version attribute for a non-Topology object should ignore that attribute. " RL: So why not to move this attribute to the Topology class? If we want to keep it in the Network object for possible extension in the future then it should be indicated clearly in the text. 3) RL: Do we really need Service and Group elements? They don't have any attributes or relations. For example, Node, Port and Link don't have Element abstract class above. Inconsistency? 4) RL: Do we need the list of attributes in 2.1.2 inherited from Network abstract class (the same for other elements)? They are already described in 2.1.1. Roman W dniu 2012-10-11 21:25, Jeroen van der Ham pisze:
Hello all,
It is with great trepidation that I present to you a draft of the "Network Markup Language Base Schema version 1".
Please have a look through it and let us/me know what you think about this document.
With the feedback we get, we will improve the document and we plan to finally start the process on this document next month.
Thanks! Jeroen.
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg
Hi, On 20 Nov 2012, at 15:49, Roman Łapacz <romradz@man.poznan.pl> wrote:
Just few comments/observations:
1) 1.1. "...Finally, you will not find a definition for the terms Network or capacity in this document" RL: ...but there is a definition (or piece of information) of Network object in 2.1.1. This might be misleading for a reader.
There is not really a definition of Network Object there. All it says is that it is an abstract class. So I don't really see a problem there. Even if we were to include a definition for Network Object there, it is very likely going to contain the word "Network", so it is still not going to provide a definition of "Network".
2) 2.1.1. "...The meaning of the version attribute is only defined for specific cases (in objects of the Topology class), and should not be used in other objects. Clients that receive a version attribute for a non-Topology object should ignore that attribute. " RL: So why not to move this attribute to the Topology class? If we want to keep it in the Network object for possible extension in the future then it should be indicated clearly in the text.
I think that that is a valid point. Doing this should not stop us from adding "version" to other objects in the future, right?
3) RL: Do we really need Service and Group elements? They don't have any attributes or relations. For example, Node, Port and Link don't have Element abstract class above. Inconsistency?
They do, the Network Object. I agree it's not the most elegant solution, the intention is to have this as an extension point for other services. We have not done so yet, but the NSI connection service could be explained as something similar. Or a Monitoring service.
4) RL: Do we need the list of attributes in 2.1.2 inherited from Network abstract class (the same for other elements)? They are already described in 2.1.1.
The idea about that is that each section stands on its own. You can look at one section and instantly know all there is to know about a single object. Jeroen.
W dniu 2012-11-29 13:01, Jeroen van der Ham pisze:
Hi,
On 20 Nov 2012, at 15:49, Roman Łapacz <romradz@man.poznan.pl> wrote:
Just few comments/observations:
1) 1.1. "...Finally, you will not find a definition for the terms Network or capacity in this document" RL: ...but there is a definition (or piece of information) of Network object in 2.1.1. This might be misleading for a reader. There is not really a definition of Network Object there. All it says is that it is an abstract class. So I don't really see a problem there. Even if we were to include a definition for Network Object there, it is very likely going to contain the word "Network", so it is still not going to provide a definition of "Network".
2) 2.1.1. "...The meaning of the version attribute is only defined for specific cases (in objects of the Topology class), and should not be used in other objects. Clients that receive a version attribute for a non-Topology object should ignore that attribute. " RL: So why not to move this attribute to the Topology class? If we want to keep it in the Network object for possible extension in the future then it should be indicated clearly in the text. I think that that is a valid point. Doing this should not stop us from adding "version" to other objects in the future, right?
3) RL: Do we really need Service and Group elements? They don't have any attributes or relations. For example, Node, Port and Link don't have Element abstract class above. Inconsistency? They do, the Network Object. I agree it's not the most elegant solution, the intention is to have this as an extension point for other services. We have not done so yet, but the NSI connection service could be explained as something similar. Or a Monitoring service.
I see your point but an empty abstract class does not look nice. One could say that a services like AdaptationService could inherit directly form Network Object. Service does not bring any thing except a kind of category. But I'm not against to keep it. Roman
4) RL: Do we need the list of attributes in 2.1.2 inherited from Network abstract class (the same for other elements)? They are already described in 2.1.1. The idea about that is that each section stands on its own. You can look at one section and instantly know all there is to know about a single object.
Jeroen.
participants (5)
-
Freek Dijkstra -
Jason Zurawski -
Jeroen van der Ham -
John MacAuley -
Roman Łapacz