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.:
- 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