Hi all, I prefer John's structured schema. Because it can specify optional or mandatory parameters and data types of each parameter, explicitly. In order for interoperability, we should define a standard schema as explicitly as possible. Thank you, Atsuko G-lambda, AIST 2011/4/12 John MacAuley <john.macauley@surfnet.nl>:
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
-- Atsuko Takefusa Information Technology Research Institute, AIST