Last night after working on this for a week I realized the labelType is really not required because of the restriction that a Port can only have a single Label, and therefore, only a single labelType. However, it still would not hurt to have it, although, it can be derived from the Port/PortGroups present. It has been over a month since I first did the edits, but if I remember correctly, I followed the existing pattern in the NML that had an ANY in the element definitions themselves. When I attempted to add the ANY to the NetworkObject I invalidated the existing elements that had an ANY member already (Universe destroying paradox where members could no longer be resolved). I agree though, refactoring all ANYs out of the specific element definitions and placing in the NetworkObject would be a clean solution. John On 2013-12-04, at 5:39 AM, Roman Łapacz <romradz@man.poznan.pl> wrote:
Hi John,
regarding the changes in the base nml xsd schema I see main two changes: 1) presence of xs:any element in each type definition 2) labelType in Switching Service
Did I miss something?
I think that in case of 1) xs:any element can be added only to NetworkObject. This way you don't have to place it in each type definition (NetworkObject is already there).
Best regards, Roman
W dniu 2013-12-04 06:06, John MacAuley pisze:
Peoples,
As promised I have done a first pass at modelling the additional NSI topology concepts in NML. I did an overview of all the components we have defined to date so we can see how they all hang together. The slide pack attached is an overview of the proposal. The XML document attacked is an updated reference topology representation, and the schema files attached are the updated NML, NSI-EXT, and service definition schemas.
John
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org https://www.ogf.org/mailman/listinfo/nsi-wg
_______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg