[Nml-wg] Review of the XSD schema
Roman Łapacz
romradz at man.poznan.pl
Wed Jan 16 04:25:36 EST 2013
W dniu 2013-01-15 19:56, Jeroen van der Ham pisze:
> Hi,
>
> Have these concerns been addressed yet?
Yes. The problem (hmm, maybe it's not a problem) I have with
xs:sequence. Unfortunately I can not use xs:all in all places I would
like. Trying to change that I was fighting with validation and ended up
with big mess in the schema and still validation errors. For the time
being I propose to have in few places this forced sequences. In the
future I'll try to change that but this may influence on many already
existing XSD structures in the schema.
Roman
>
> Jeroen.
>
> On 27 Dec 2012, at 15:34, Freek Dijkstra <freek.dijkstra at 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 at ogf.org
>> https://www.ogf.org/mailman/listinfo/nml-wg
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg
More information about the nml-wg
mailing list