Hi Aaron,

Thanks for your email. I now start to understand your take on idRef.

On Sep 21, 2012, at 7:08 AM, Jeroen van der Ham wrote:

I actually meant it more like the following:

<nml:Port id="urn:ogf:network:example.net:2012:port-X:out">

<nml:Label encoding="http://schemas.ogf.org/nml/2012/10/ethernet/vlan">1501</nml:Label>

<nml:Relation type="http://schemas.ogf.org/nml/2012/10/relation/isSource">

  <nml:Link id="urn:ogf:network:example.net:2012:linkA:XY">

    <nml:Relation type="http://schemas.ogf.org/nml/2012/10/relation/isDefinedBy">

      http://example.com/topology-description.xml

    </nml:Relation>

  </nml:Link>

</nml:Relation>

</Port>

On Sep 21, 2012, at 10:34 AM, Aaron Brown wrote:

The implication of isDefinedBy here is that all topology is an HTTP

GET away. I'm not sure I like encoding "how to get remote topologies"

into the base schema defining how we represent topology. As an

extension, it might be reasonable, but not in the base.

I agree with Aaron that this seems a bit limited. For one thing, I also
like to be able to say that something is a reference, even if I don't
know the URI where it is published (think about a domain that supports
NML + NSI, which is connected to a domain which does not yet have a NML
description published)

I'm sure we can fix it, but the bottom line is that the is really a
control plane construct, and that is -with good reason- out of scope of
NML. A NSI extension is perhaps more logical. I wonder if the same
applies to isReference/idRef.

Beyond my above complaint, if it was of the form:

 <link id="ABC">

   <relation type="defined-by">

     <link id="XYZ">

   </relation>

 </link>

I'd be more okay with it.

I think we already have this in the form of:

 <link id="ABC">
   <relation type="alias">
     <link id="XYZ">
   </relation>
 </link>

(though I like your name 'is-defined')

<topology>

 <relation type="hasNode">

   <node id="a">

   </node>

 </relation>

</topology>

Now, if a parser is looking at representation two, is it supposed to

lookup node definition 'a' elsewhere? It's implicit in the examples that

we have that the "id" element really means "go look elsewhere for this"

which it isn't supposed to mean.

Could you detail your use case a bit more?

I think you mean that a parsers which encounters the above like to
distinguish between the case where it can just instantiate a Node object
"A", and the case where there is not enough detail known. In the later
case, the parser is supposed to either look up the details elsewhere
(either elsewhere in the file, or with another query) or don't
instantiate the object, but use a reference/pointer.

Is that a correct interpretation of your mail?


I'm trying to understand what the real use case is here.
It seems that the most simple NML use case is an organisation that likes
to describe its network topology using a Topology object. Since NML does
not use a hierarchical namespace, it is useful to denote to others which
part of the description are part of the Topology, and which descriptions
are merely pointers to other Topologies.

Is isReference/idRef necessary for this in the first place? Would it
also be possible to e.g. that only objects with a hasNode,
hasInboundePort, hasOutboundPort and hasLink (which would be a new
implicit relation) are part of the Topology, and the rest -by
definition- is not?