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