[Nml-wg] [Nsi-wg] NSI Topology

[John MacAuley]

Roman,

I figured you what the original issue was with including ANY in the Network Object definition.  There is no problem refactoring the NML base schema, but Jeroen's NSI extensions document will now break.  The reason is his new NSI objects extend from the Network Object as well.  With an ANY in the Network Object the parsers cannot determine if the elements defined in is NSAType are meant to be included as an ANY extension to the Network Object, or as members of the NSAType.  This is due to the fact that the NSAType is defined in an external namespace.  It does not seem to have an issue with attributes, only the elements.

  <xs:complexType name="NSAType">
    <xs:complexContent>
      <xs:extension  base="nml:NetworkObject">
        <xs:sequence>
          <xs:element  ref="nsi:Interface" minOccurs="0"  maxOccurs="unbounded"/>
          <xs:element  ref="nsi:Relation"  minOccurs="0"  maxOccurs="unbounded"/>
          <xs:element  ref="nml:Topology"  minOccurs="0"  maxOccurs="unbounded"/>
        </xs:sequence>
      </xs:extension>
    </xs:complexContent>
  </xs:complexType>

So do we go forward with the individual ANY elements in all the NML types, or can you think of alternatives?  I guess we could stop the NSI extensions types extending from Network Object. 

Thanks,
John

On 2013-12-04, at 9:53 AM, John MacAuley <john.macauley at surfnet.nl> wrote:

> 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 at 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 at ogf.org
>>> https://www.ogf.org/mailman/listinfo/nsi-wg
>> 
>> _______________________________________________
>> nml-wg mailing list
>> nml-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/nml-wg
> 
> _______________________________________________
> nsi-wg mailing list
> nsi-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nsi-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20131210/5ea1f494/attachment.html>