[Nml-wg] XML Examples and Proposals

[Freek Dijkstra]

Jason Zurawski wrote:

> I am attaching my commentary as a text file.  I will note that this is a 
> *lot* of information to process at a single time (which is frustrating), 
> and your examples are spread over multiple files (with references within 
> each file, also frustrating).  Commentary became very challenging in 
> this format, A better collaboration method will be needed I fear ...

It is indeed a lot to process, thank you very much for going through it.
I tried to stick to a single topic within a file, and list alternatives
within that same file.

I wanted to finish it because I know it was challenging, and I only had
this week I have time to explain in person to some group members. I also
anticipated that I would have to do some more explaining next weeks, so
I'm thoroughly impressed that you found time to look through it on such
short notice. Kudos.

> Given that, here is a quick executive summary:
> 
>   - The concept of the alias topo is not very foreign (and a private 
> topo that can related to some other is a good thing to care about), but 
> I fear that we are trying to do 'too much' at the schema level here. 
> Private topos can be protected at a higher layer from being shared. 
> Because of this, I would claim that a public/private topo are both at 
> the same 'level', and can be related, and shouldn't be defined within 
> each other.

I'm currently only concerned *that* they can be related, similar how a
node can be related to a topology. I agree that they don't have to be
defined within each other, and am fine if they simply refer to each
other. It should be perfectly fine to either:

 * Specify a topology with all details.
 * Specify a topology without specifying details, leaving out internal
   subtopologies, Nodes, etc.
 * Specify a topology with some details, e.g. giving a hasTopology
   relation and using a idRef, thus without the details of the
   subtopology

> Because of this, I would claim that a public/private topo are both at
> the same 'level', and can be related, and shouldn't be defined within
> each other.

Do you mean same XML 'level'? e.g.:

 <nml:Topology id="aaaaaaa">
   <nml:Relation type="hasSubtopology">
     <nml:Topology idRef="urn:ogf:network:a.net:subtopo"/>
   </nml:Relation>
   ...
 </nml:Topology>
 <nml:Topology id="urn:ogf:network:a.net:subtopo">
   ...
 </nml:Topology>

>   - Defining first order elements in relations is problematic for 
> referencing them elsewhere (even if they are meant to be private).  We 
> need to be careful about this

I'm sorry, I don't understand this. Does "first order elements" mean
"root XML elements" or "direct child elements"?


Do we perhaps have a different view on the use of nml:Topology? For me
it is just a Network Object, kind of similar to a Node (in that it has
Ports, and a name). nml:Topology does not have to be the root XML
element (though I think it usually will be, even if it is for
referencing purposes).


>   - Some things have an explicit parent/child relationship already (e.g. 
> we know a topology contains nodes, ports, links).  Using a relationship 
> to say 'hasNodes' or something similar is redundant, we know they are 
> involved with the topology due to the nature of the schema.

Agreed that it is not necessary. I did it for consistency. E.g. if
Topology -> Topology, Node -> Port, Node -> Service are all explicit
(hasTopology, hasPort/hasOutboundPort, hasService), it makes sense to
also use hasNode. Or we define some others redundant too. (e.g. a
Service in a Node always implies hasService, a Topology in a Topology
always implies a hasTopology, etc.)


>   - I see no benefit to the 'version' concept over 'lifetime', in fact i 
> believe it limits us more.  Your use of lifetime (as a relation) is not 
> really correct.  Aaron should provide you with examples of how we use 
> this as a first order element.

I came to realise that lifetime and version are two different concepts.

A lifetime signifies a duration (e.g. of a reserved link), while a
version is a sequence number to track updates of a 'document' (where
'document' is a network description).

Comparing them side-by-side was probably a mistake of mine, that could
have lead to misunderstanding, chaos and the downfall of civilisation.


>   - Lifetimes (or versions) should be associated with a 1st order 
> element in my opinion, not a relation (which is an action of an element, 
> and not a first order element).  This is a bit cleaner, and can be 
> explicitly searched/found.

It indeed makes it easier to parse.

I'll wait and see if there are some other use cases, but for now I'm
inclined to agree with you. (At least, my gut feeling tells me that I
dislike associating a version number to a Relation, though I have less
reservations to associate it with other non-root Network Objects).

Thanks,
Freek