On Jun 16, 2011, at 9:07 AM, Freek Dijkstra wrote:
Freek Dijkstra wrote:
During today's call we agreed to have another conference call in two weeks time.
The next NML call is scheduled on June 16th at UTC 15:00 = 8:00 PDT = EDT 11:00 = 17:00 CEST.
Call: +1-734-615-7474 (Please use if you do not pay for Long Distance) or +1-866-411-0013 (toll free US/Canada Only) Enter access code: 0186145
Jeroen and I today have been looking at the NML RNC schema that Roman Łapacz wrote some time ago.
Some initial comments:
--- nmlbase20110421.rnc 2011-06-16 11:02:32.000000000 -0400 +++ nmlbase20110616.rnc 2011-06-16 10:56:20.000000000 -0400 @@ -40,17 +42,19 @@
Relation = element relation { - attribute type { xsd:string } - & IdReference* - & anyElement* + attribute type { xsd:anyURI } + & ( BaseNode | BaseLink | BasePort | BaseService | NMLGroup | Container ) }
+# problem: hasPort, hasport, has_port are not equal. Risk is less with URI's. +# risk of proliferation of types. E.g. Port -hostname-> Node instead of Node -hasport-> Port +
I think this is going to be a problem no matter what. If it's a URI, folks can still define junk relationships. I'm not opposed to it, per se; though, I'd like to see some specifics of what kinds of URIs you're thinking of.
Lifetime = element lifetime { StartTime & (EndTime | Duration)? } - +### May a lifetime be segmented? (thus multiple sets of begin/endtime?)
It's probably just an optimization so i'd rather keep things simple, if possible. I think, in general, the same element may appear with different lifetime elements. For example, at time X, a virtual port's capacity is increased (the ports id is Y). Now we have the same element, Y, with a different set of properties (pre-X and post-X). If we change Y, we'll need to update everything pointing at Y with the new id. If we keep Y the same, when users lookup the element, they'll find two with different lifetimes, and it's up to them to figure out the correct one for their situation. I think the latter makes the most sense (if nothing else, it avoids nasty update loops when elements A and B have pointers at each other, and one gets updated. if A gets updated, it becomes A', so B gets updated, and now points at A', but it needs to be changed to B', so A' needs updated to point to B', and becomes A'', etc).
# ################################################################# # This sequence allows any element, attribute, or text (regardless @@ -78,14 +82,13 @@ ## ########################
StartTime = - anyElement* + element start { xsd:dateTime }
EndTime = - anyElement* + element end { xsd:dateTime }
Duration = - anyElement* - + element duration { xsd:duration }
The ISO duration looks truly ugly IMO, but I'm fine with swapping these to use more standardized formats.
## ######################## ## Generic location @@ -106,17 +109,17 @@ & element shelf { xsd:string }? & element latitude { xsd:float }? & element longitude { xsd:float }? - +### NAME?
I'd not mind being able to name locations.
## ######################## ## Generic link ## ########################
-BaseLink = element link { BaseLinkContent } +BaseLink = element link { BaseLinkContent | NetworkObjectRef } BaseLinkContent = NetworkObject & element type { xsd:string }? - & element capacity { xsd:string }? + & element capacity { xsd:float }? & anyElement*
I like specifying capacity as a float instead of an arbitrary string.
## ######################## ## Generic service ## ########################
-BaseService = element service { BaseServiceContent } -BaseServiceContent = - NetworkObject - & anyElement* +BaseService = + AdaptationService + | SwitchingService + +AdaptationService = anyElement +SwitchingService = anyElement
I'm not sure about limiting the services to AdaptationService and SwitchingService in the initial RNC file. At minimum, adding an 'AnyService' that is also anyElement would be good.
+## ######################## +## Containers +## ######################## + +## A container is a list of items. A list may be unordered (a Bag) or ordered (a Sequence) + +Container = + Bag + | Sequence + +Bag = + element bag { UnorderedItem* } + +UnorderedItem = + element * { NetworkObject | NetworkObjectRef } + +Sequence = + element list { attribute first { xsd:anyURI } OrderedItem* } + +UnorderedItem = + element * { + attribute next { xsd:anyURI } + | attribute last { xsd:empty } + anyThing + } +
I'll need to think about this some more. I'm curious about the UnorderedItem. They've got "next" and "last" elements which implies an ordering of some kind. Cheers, Aaron Summer 2011 ESCC/Internet2 Joint Techs Hosted by the University of Alaska-Fairbanks http://events.internet2.edu/2011/jt-uaf