Thank you for the comments. I have added comments below. On 2011-03-23, at 10:49 PM, Atsuko Takefusa wrote:
Hi all,
I have several comments on the current schema as below. Thanks,
Atsuko (AIST, G-lambda)
--
* CommonParametersGroup - transactionId Who determines transactionId? It should be minOccurs=”0” if providers do.
The agreement was that the requester must provide the value.
* ReservationGroup - connectionId As above, it should be minOccurs=”0” if provider does.
Likewise the requester must provide the value.
* ScheduleType - startType Does the first release support immediate reservation? If support, startType shold be minOccurs=”0” or a new parameter should be defined.
The agreement was to remove the immediate type and just set the start time to the time of the request.
- duration xsd:long is better than xsd:integer. In addition, it’s unit is not explicitly defined in the schema. In the G-lambda’s schema, we define duration as follows: <xsd:complexType name="Duration_Type"> <xsd:sequence> <xsd:element ref="rdl:DurationValue"/> <xsd:element ref="rdl:TimeUnit"/> </xsd:sequence> </xsd:complexType> <xsd:element name="DurationValue" type="xsd:long"/> <xsd:simpleType name="TimeUnit_Type"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="MILLISECOND"/> <xsd:enumeration value="SECOND"/> <xsd:enumeration value="MINUTE"/> <xsd:enumeration value="HOUR"/> <xsd:enumeration value="DAY"/> <xsd:enumeration value="WEEK"/> <xsd:enumeration value="MONTH"/> <xsd:enumeration value="YEAR"/> </xsd:restriction> </xsd:simpleType>
I was actually thinking of changing this to the "xsd:duration" type which provides a standard way of describing duration.
* BandwidthType It’s unit is not explicitly defined in the schema. The G-lambda’s schema defines as follows: <xsd:complexType name="GeneralBW_Type"> <xsd:sequence> <xsd:element ref="ndl:Rate" minOccurs="1" maxOccurs="1" /> <xsd:element ref="ndl:BWUnit" minOccurs="1" maxOccurs="1" /> </xsd:sequence> </xsd:complexType> <xsd:element name="Rate" type="xsd:int"/> <xsd:simpleType name="BWUnit_Type"> <xsd:restriction base="xsd:string"> <xsd:enumeration value="Pbps"/> <xsd:enumeration value="Tbps"/> <xsd:enumeration value="Gbps"/> <xsd:enumeration value="Mbps"/> <xsd:enumeration value="kbps"/> <xsd:enumeration value="bps"/> </xsd:enumeration> </xsd:restriction> </xsd:simpleType>
I put it in the comment that it must be Mbps. Do we really need the distinction? Anyone really want to specify less that Mbps? I have no issue adding it if people agree.
* OrderedServiceTerminationPointType - order <xsd:attribute name="order" type="xsd:integer"/> should be removed. Because each array order is ensured in SOAP messages and we (provider and aggregator) have to renumber if STPs are inserted or removed.
Very interesting. I will need to check into that. I was not sure if a sequence was maintained in order during conversion from XML to Java.
* namespace I think that namespace is generally defined in OGF schemas as follows: namespace="http://schemas.ogf.org/nsi/2011/03/connection" ("http://www.ogf.org/schema/nsi/connection/v1_0/types") E.g., JSDL : "http://schemas.ggf.org/jsdl/2005/11/jsdl" GLUE : "http://schemas.ogf.org/glue/2008/05/spec_2.0_d42_r01"
Yes, I still have an action item to get a namespace allocated.
2011/3/24 John MacAuley <john.macauley@surfnet.nl>:
Peoples,
I have attached an XML file that contains an example reservation request message. Ignore the namespace information and the schemaLocation statement as these would not be included within the SOAP message.
John.
_______________________________________________ nsi-wg mailing list nsi-wg@ogf.org http://www.ogf.org/mailman/listinfo/nsi-wg
-- Atsuko Takefusa Information Technology Research Institute, AIST