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

[Roman Łapacz]

W dniu 2013-12-10 17:43, John MacAuley pisze:
> Roman,

Hi John.

>
> 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:complexTypename="NSAType">
> <xs:complexContent>
> <xs:extensionbase="nml:NetworkObject">
> <xs:sequence>
> <xs:elementref="nsi:Interface"minOccurs="0"  maxOccurs="unbounded"/>
> <xs:elementref="nsi:Relation"  minOccurs="0"  maxOccurs="unbounded"/>
> <xs:elementref="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?

If we have such problem I think ANY elements in all the NML types is the 
best choice because it would be good to use nml:NetworkObject also in 
the extensions. Inheritance from nml:NetworkObject standardises type 
definitions also in the extensions (gives a basic set of elements which 
should be included by all objects that we can call network objects).

Best regards,
Roman

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