[Nml-wg] References

[Aaron Brown]

On Sep 24, 2012, at 10:01 AM, Freek Dijkstra wrote:

> 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?


Note: I'll be using "named" here to mean an element with an 'id' attribute.

The problem is ambiguity. If I can define a new, named object inside of a relation element, how does a parser know that the named object inside the relationship is defined there, as opposed to elsewhere?

e.g. 

In our examples:

<port id="A">
  ...
</port>

<node id="N">
   <relation type="hasPort">
     <port id="A">
   </relation>
</node>

is semantically identical to:

<node id="N">
   <relation type="hasPort">
     <port id="A">
       ...
     </port>
   </relation>
</node>

In the latter case, however, how does someone who receives the topology supposed to know that this is the canonical definition of 'A', and they should not be looking for another definition of A elsewhere (e.g. should this be an error, or not per your discussion of in-document references vs. out-of-document references)?  

Using defined-by, the proper way to write the first thing above is:

<port id="A">
  ...
</port>

<node id="N">
  <relation type="hasPort>
    <port>
      <relation type="definedBy">
        <port id="A" />
      </relation>
    </port>
  </relation>
</node>

Though, this retains the ambiguity since, theoretically, you could define a named port inside the "definedBy" relationship.

Now, we could say that the "definedBy" relationship is a special-case, and you can't define a new element there, so the elements in there must have another definition elsewhere, but we have to be clear about that point.

Cheers,
Aaron

Internet2 Fall Member Meeting
Sep 30-Oct 4, 2012 - Philadelphia, PA
http://events.internet2.edu/2012/fall-mm/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120927/74e85cf5/attachment.html>