Hi, Attached is a new draft of the topology representation Schema. It features an example written in N3 to make it easier for human consumption, and should be fairly obvious. The final document will only have an OWL and XML representation of the example, to align with the NML doc. Please let me know what you think. Jeroen.
Hi Jeroen On Wed, 22 May 2013, Jeroen van der Ham wrote:
Attached is a new draft of the topology representation Schema.
It features an example written in N3 to make it easier for human consumption, and should be fairly obvious.
The final document will only have an OWL and XML representation of the example, to align with the NML doc.
OK. Since we are going with XML as the mandatory format, I would expect that to be in such a document.
Please let me know what you think.
3.1.1 This section leaves out the cs[2]ProviderEndPoint which we have previously used. However I think that the service class makes much more sense. 3.1.2 + 3.3 The term "link" is an odd choice IMHO. The common term for this is "url", or occasionally "endpoint" (main used with web services). I think the term "link" is particularly unfortunate as it occurs in describing network topology, where this word typically has another meaning. 5. The main reason we decided on a single format in Charlottesville, was so implementations would know exactly what that must be exported and must be able to parse. Hence I think that the "SHOULD" for parsing OWL syntax should be relaxed to "MAY" or "OPTIONAL". The OWL example includes nsi:cs2ProviderEndpoint despite not being specified in the document. I think it can just be removed. Should nml:Topology in the top be a nml:Node? I am left a bit puzzled about when to use topology and node now. Same with Port and PortGroup (I'll admit to now having read the full nml spec). Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet
Hi, Here's a first attempt at an XML version of the topology description. On 24 May 2013, at 15:13, Henrik Thostrup Jensen <htj@nordu.net> wrote:
Please let me know what you think.
3.1.1
This section leaves out the cs[2]ProviderEndPoint which we have previously used. However I think that the service class makes much more sense.
I believe we agreed in Charlottesville that we would go for the Services class to be in line with the Discovery Service description of services.
3.1.2 + 3.3
The term "link" is an odd choice IMHO. The common term for this is "url", or occasionally "endpoint" (main used with web services). I think the term "link" is particularly unfortunate as it occurs in describing network topology, where this word typically has another meaning.
This is in line with the Discovery Service, and I think John took this from other recommendations or implementations.
5.
The main reason we decided on a single format in Charlottesville, was so implementations would know exactly what that must be exported and must be able to parse. Hence I think that the "SHOULD" for parsing OWL syntax should be relaxed to "MAY" or "OPTIONAL".
The OWL example includes nsi:cs2ProviderEndpoint despite not being specified in the document. I think it can just be removed.
Should nml:Topology in the top be a nml:Node? I am left a bit puzzled about when to use topology and node now. Same with Port and PortGroup (I'll admit to now having read the full nml spec).
A Topology describes a network domain, and it can act like a Node. Theoretically, there is no difference between a Node and a Topology. Practically it's often easier to be able to differentiate between them. Jeroen.
Hi, This is a more complete XML example. I've renamed the two networks to make the difference more obvious. This is verified valid against both NML and the new NSI extension schema (also attached). Thank you Roman! Jeroen.
participants (2)
-
Henrik Thostrup Jensen -
Jeroen van der Ham