[Nml-wg] Conference call Thu June 16nd

[Aaron Brown]

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/nml-wg/attachments/20110616/f1390f15/attachment.html