Re: [Nsi-wg] NSI CS XSD comments

13 Apr 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@kddilabs.jp>
To: "John MacAuley" <john.macauley@surfnet.nl>, "Jerry Sobieski" <jerry@nordu.net>
Cc: nsi-wg@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@ogf.org
http://www.ogf.org/mailman/listinfo/nsi-wg
--
Takahiro Miyamoto <tk-miyamoto@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]