Hi Freek/All; 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 ... 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. - 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 - 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. - 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. - 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. Thanks; -jason On 3/9/12 3:49 PM, thus spake Freek Dijkstra:
Hi Guys,
I hope you like XML.
I've just filled the nml-example repository with a whole bunch of examples and proposals that I like to go through next week at the OGF.
If you haven't checked it out, do so now: svn checkout --username YourGridForgeName \ https://forge.ogf.org/svn/repos/nml-examples
If you get a permission error, let me know off-list. The examples are also attached to this mail, but be aware that I may improve some typos and add clarifications in the coming days.
The examples and proposals are:
subtopology - hasNode four alternative proposals how to relate a topology and a node
subtopology - hasTopology one example and three questions how to relate a topology to a subtopology (hopefully trivial after we decided on hasNode)
subtopology - inbound-outbound-ports four proposals to decide on the term for ingress and egress ports
subtopology - alias three proposal to relate a external port of a topology with its internal structure
versioning - lifetime a (surely flawed) example how I interpreted Aaron's description of the current use of lifetime in IDC.
versioning - aliases-lifetime versioning - aliases-version six proposals to describe the changes in a network over time using either a lifetime object or a version attribute
vlans - compoundlink two questions on the exact name of the source/sink relation and the serial compound link relation
vlans - vlan a proposal to describe vlans (Ethernet subnets) between hosts
vlan - shared-switchingservice vlan - multiple-switchingservice <not yet written -- will follow sunday or monday> two proposals to describe multiple VLANs as one or more switching services inside a single node
In case you wonder "haven't we decided on that already" -- in most cases, "yes" -- while going through previous examples, I've noted some small discrepancies. For examples some examples used "source" relation, while others used "hasSource". I don't care, so we should decide, and that's what this is about: make sure that we make a decision. Note the consensus and make the decision authoritative, so we can refer back to it, and update the previous examples to comply with the decision.
I did my best to make all proposals stand on it's own, and VERY much hope that the decision for most proposals is a formality without discussion.
Regards, Freek