[Nml-wg] XML Examples and Proposals
Jason Zurawski
zurawski at internet2.edu
Mon Mar 12 16:54:46 EDT 2012
Hi Freek/All;
On 3/12/12 1:15 PM, thus spake 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
This all sounds fine to me.
>> 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>
Yes, basically have them be defined independently and linked later as
you note here. 2 quick use cases:
- Internet2 network topology, and then the sub topology for ION and
NDDI, which are both 'owned' by Internet2 and use the same footprint.
These may all live in the same service, and probably wont be defined at
the same time (although they could be).
- Internet2 NDDI topology, and then an experimental openflow topology
defined by some experiment external to Internet2 (e.g. GENI). It will
be the case these live in different services.
>> - 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).
I am thinking of situations like this:
<topo id=1>
<relation>
<topo id=2>
<!-- all of the info on this -->
</topo>
</relation>
</topo>
<topo id=3>
<relation>
<!-- just a reference -->
<topo id=2 />
</relation>
</topo>
Unless we exhaustively unrolled the fact that the topo #2 was defined
inside of a relation in another topo (#1), its hard for #3 to make a
reference to it. Does this help?
>
>> - 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.)
This really bashes the argument of needing a well defined schema though.
If everything is related to other things via relationships (and we
never use the explicit parent/child), we end up with this:
- Node, Port, Topology, Link, etc. etc. don't contain anything except
relationships
- Relationships allow 'any element' to be inside
- 'Rules' are all semantic for each relationship type
- schematic checking is useless
Wasn't it you who argued a couple of months ago that we need well
defined schema so that we know what each element can/may contain :) ?
I agree with your line of reasoning that is hast to be consistent in our
use of parent/child vs relationships, and this was a minor mistake on my
examples from Sept as I read them now.
At least in my mind, I would *like* to interpretation the relationship
for logical or fuzzy concepts:
- Serial compound pushes together two links
- two ports are pushed together into a bidirectional
- a switching service has inbound and outbound ports associated with it
- a link needs to describe the in vs out ports
I would claim that we don't need these in a relation, and this may force
some example changes:
- a switch won't need 'hasports' by itself sine we know the switch has
the ports via parent/child.
- A switch can have 'hasinbound' or 'hasoutbound' port relations, as
this adds more value
- A topology with 'hasnodes' doesn't seem necessary, we know it has
nodes (and ports and links).
- A node with 'providesService', the service could be a direct
parent/child (unless its special maybe, I dont have a good use case)
I could be wrong of course, but this seems to make sense as I type it.
We should try to use explicit things when we can.
>> - 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).
then why not use the versioned namespace? Thats why we put versions in
namespaces?
<nml1:topo />
<nml2:topo />
Where these prefixes are slightly different namespaces. Perhaps I am
missing the distinction ...
Thanks;
-jason
> 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
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg
More information about the nml-wg
mailing list