Hi, Have these concerns been addressed yet? Jeroen. On 27 Dec 2012, at 15:34, Freek Dijkstra <freek.dijkstra@sara.nl> wrote:
Here is my review of the XSD schema. Since I'm less verbose in XSD, it's mostly a series of questions.
First of all I really like to compliment Roman -- you have been able to even add rather complex constructs like implicit and explicit relations. I also now understand the pros and cons of XSD much better (after having read parts of the primer http://www.w3.org/TR/xmlschema-0/, as well as the discussion http://www.imc.org/ietf-xml-use/mail-archive/msg00217.html and rebuttal http://www.imc.org/ietf-xml-use/mail-archive/msg00261.html -- see further follow-ups for a nice cozy flamewar which may keep you warm during the long cold nights during this winter season.)
General questions and remarks: ------------------------------
* Where does it specify that all NML descriptions should start with nml:Topology as the root element?
* In the current schema, the order of child elements is very strict -- it is a sequence of elements in particular order. For example, a relation element MUST occur before a Location element. If relation occurs after a Location, the document is invalid.
Here is an excerpt for the schema:
<xs:complexType name="NetworkObject"> <xs:sequence> <xs:element name="name" type="xs:string" minOccurs="0" maxOccurs="1"/> <xs:element name="relation" type="nml:RelationType" minOccurs="0" /> <xs:element name="Location" type="nml:LocationType" minOccurs="0" maxOccurs="1"/> <xs:element name="parameter" type="nml:ParameterType" minOccurs="0"/> <!-- .... --> </xs:sequence> <!-- .... --> </xs:complexType>
Instead, I would suggest to use xs:all:
<xs:complexType name="NetworkObject"> <xs:all> <xs:element name="name" type="xs:string" minOccurs="0" maxOccurs="1"/> <xs:element name="relation" type="nml:RelationType" minOccurs="0" /> <xs:element name="Location" type="nml:LocationType" minOccurs="0" maxOccurs="1"/> <xs:element name="parameter" type="nml:ParameterType" minOccurs="0"/> <!-- .... --> </xs:all> <!-- .... --> </xs:complexType>
In XSD 1.0, this would limit the maxOccurs to 1, but XSD 1.1 no longer has that restriction. Given that XSD 1.0 and XSD 1.1 use the same namespace, perhaps it is good to make this explicit:
<xs:complexType name="NetworkObject"> <xs:all> <xs:element name="name" type="xs:string" minOccurs="0" maxOccurs="1" /> <xs:element name="relation" type="nml:RelationType" minOccurs="0" maxOccurs="unbounded" /> <xs:element name="Location" type="nml:LocationType" minOccurs="0" maxOccurs="1" /> <xs:element name="parameter" type="nml:ParameterType" minOccurs="0" maxOccurs="unbounded" /> <!-- .... --> </xs:all> <!-- .... --> </xs:complexType>
* I don't really understand how you are trying to deal with implicit and explicit relations. This seems at first very powerful (meaning: either use implicit or explicit):
<xs:choice> <xs:element name="lifetime" type="nml:LifeTimeType" minOccurs="0" maxOccurs="1"/> <xs:element name="existDuring" type="nml:ExistDuringType" minOccurs="0" maxOccurs="1"/> </xs:choice>
In fact there are four ways to represent implicit relations:
1.
<nml:Node id="..."> <nml:name>My Device</nml:name> <nml:Location> <nml:name>Somewhere</nml:name> </nml:Location> </nml:Node>
2.
<nml:Node id="..."> <nml:name>My Device</nml:name> <nml:Relation type="http:....nml/base#locatedAt"> <nml:Location> <nml:name>Somewhere</nml:name> </nml:Location> </nml:Relation> </nml:Node>
3.
<nml:Node id="..."> <nml:name>My Device</nml:name> <nml:Location id="..." /> </nml:Node> <nml:Location id="..."> <nml:name>Somewhere</nml:name> </nml:Location>
4.
<nml:Node id="..."> <nml:name>My Device</nml:name> <nml:Relation type="http:....nml/base#locatedAt"> <nml:Location id="..." /> </nml:Relation> </nml:Node> <nml:Location id="..."> <nml:name>Somewhere</nml:name> </nml:Location>
Currently, for Location/locatedAt only the form 1 seems allowed. For LifeTime/existDuring only forms 1 and 3 seem allowed.
Is this on purpose? (I presume it is on purpose that the explicit variants are not listed, but that the missing form #3 for Location is a omission.)
* To iterate on existsDuring: It seems that the described form it even slightly different:
<nml:Node id="..."> <nml:name>My Device</nml:name> <nml:existDuring idRef="..." /> </nml:Node>
(thus without the <nml:LifeTime> wrapper)
Is that interpretation correct?
* The RelationType lists all possible relation URIs as values for the type attribute. Is it permitted to use a URI not listed here? Thus, is is possible to define a new relation in nml-experimental, without changing nml-base?
Specific remarks: -----------------
<xs:attribute name="idRef" type="xs:anyURI" use="optional"/> Remove line 32, as idRef is no longer used:
<xs:element ref="nml:Port" minOccurs="1"/>
Remove minOccurs on line 40: (perhaps the minOccurs should be listed elsewhere?)
<xs:attribute name="version" type="xs:unsignedInt" use="optional"/> version type should be a dateTime on line 33:
For readability, I suggest to put xsd:attribute before xsd:elements, in particular for NetworkObject and RelationType. (Simply because attributes also come earlier in a document).
<xs:element name="relation" type="nml:RelationType" minOccurs="0" />
* relation: should be capitalized as Relation on line 23:
Missing relation (lines 48-55): - canProvidePort (I assume that the implicit relations are not listed on purpose)
<xs:element name="duration" type="xs:duration" minOccurs="0" maxOccurs="1"/>
LifeTime does not have a duration (only a end):
LifeTime should not have an id attribute.
Location should have an id attribute.
Note: I have not yet looked at the cardinalities (minOccurs and maxOccurs) yet, and only reviewed about the first 100 lines, so this is an incomplete list of remarks.
Freek _______________________________________________ nml-wg mailing list nml-wg@ogf.org https://www.ogf.org/mailman/listinfo/nml-wg