[Nsi-wg] NSI CS XSD comments

John MacAuley john.macauley at surfnet.nl
Wed Apr 13 10:06:03 CDT 2011


This is good input.  Last month I had written up a version that used the <xsd:any> to allow for inclusion of technology and deployment specific elements not defined in the core schema.  In this case you would have the parent schema that could include addition schema elements in the instance document.  This is an inverse to the extension strategy, but perhaps a good way to include other concrete schemas?

   <!-- Parameters relating to the requested service. -->
   <xsd:complexType name="ServiceParametersType">
      <xsd:sequence>
         <!-- Time parameters relating to the reservation. -->
         <xsd:element name="schedule" type="tns:ScheduleType"/>
         <xsd:element name="bandwidth" type="tns:BandwidthType"/>
         <xsd:element name="directionality" type="tns:DirectionalityType"/>
         <xsd:element name="pathObject" type="tns:PathObjectType"/>
         <xsd:element name="guaranteed" type="tns:AnySequenceType" minOccurs="0"/>
         <xsd:element name="preferred" type="tns:AnySequenceType" minOccurs="0"/>
      </xsd:sequence>
   </xsd:complexType>
 
    <!-- A generic sequence of <any> for inclusion of external elements from external schema. -->
   <xsd:complexType name="AnySequenceType">
      <xsd:sequence>
         <xsd:any namespace="##other" processContents="lax" maxOccurs="unbounded" />
      </xsd:sequence>
   </xsd:complexType>

John.

----- Original Message -----
> From: "Takahiro Miyamoto" <tk-miyamoto at kddilabs.jp>
> To: "John MacAuley" <john.macauley at surfnet.nl>, "Jerry Sobieski" <jerry at nordu.net>
> Cc: nsi-wg at ogf.org
> Sent: Wednesday, April 13, 2011 12:40:11 AM
> Subject: Re: [Nsi-wg] NSI CS XSD comments
> Hello John and Jerry,
> 
> I want to separate generic parameters from service-specific
> parameters.
> G-lambda interface introduced xsd:extension to inherit generic
> parameters in service-specific definition.
> Please find attached the sample xsd of general and service-specific
> definitions and the ppt describing parameter descriptions and usage
> scenario.
> By using xsd:extension, we don't need to list all service parameters
> in
> a xsd.
> 
> I want to explain and discuss this methodology in today's conf call.
> 
> Best regards,
> Takahiro
> 
> 
> John MacAuley wrote:
> > Peoples,
> >
> > I think there is one major area we need to close on before I feel
> > comfortable starting to write the associated document. It is
> > specifically around the service parameters and how they are
> > specified:
> >
> >   <!-- Parameters relating to the requested service. -->
> >    <xsd:complexType name="ServiceParametersType">
> >       <xsd:sequence>
> >          <!-- Time parameters relating to the reservation. -->
> >          <xsd:element name="schedule" type="tns:ScheduleType"/>
> >          <xsd:element name="bandwidth" type="tns:BandwidthType"/>
> >          <xsd:element name="directionality"
> >          type="tns:DirectionalityType"/>
> >          <xsd:element name="pathObject" type="tns:PathObjectType"/>
> >          <xsd:element name="guaranteed"
> >          type="tns:AttributeSequenceType" minOccurs="0"/>
> >          <xsd:element name="preferred"
> >          type="tns:AttributeSequenceType" minOccurs="0"/>
> >       </xsd:sequence>
> >    </xsd:complexType>
> >
> > The main question I have is do we change this structure to be
> > completely generic and list all service parameters through
> > type/value pairs, or do we break out hose key ones as I have here
> > and put the remaining in the type/value pairs?
> >
> > Also, for bandwidth do we document the values as Mb/s or do I add an
> > element to explicitly identify the unit as suggested in one provided
> > comment.
> >
> > Thank you,
> > John.
> >
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________
> > nsi-wg mailing list
> > nsi-wg at ogf.org
> > http://www.ogf.org/mailman/listinfo/nsi-wg
> 
> --
> Takahiro Miyamoto <tk-miyamoto at kddilabs.jp>
> Integrated Core Network Control And Management Laboratory
> KDDI R&D Laboratories, Inc.
> TEL: +81-49-278-7455 / FAX: +81-49-278-7811
> 
> 
> [XML:OpticalServiceDefinition.xsd]
> 
> 
> [XML:GeneralServiceDefinition.xsd]
> 
> 
> [XML:EthernetServiceDefinition.xsd]
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/xml
Size: 2170 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110413/4cf75813/attachment.xml 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/xml
Size: 2624 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110413/4cf75813/attachment-0001.xml 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/xml
Size: 3164 bytes
Desc: not available
Url : http://www.ogf.org/pipermail/nsi-wg/attachments/20110413/4cf75813/attachment-0002.xml 


More information about the nsi-wg mailing list