[Nml-wg] XML Examples and Proposals

[Jason Zurawski]

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
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 20120311-nml_comments.txt
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20120312/c388c5bb/attachment.txt>