[Nml-wg] Review of the XSD schema

Freek Dijkstra Freek.Dijkstra at surfsara.nl
Wed Jan 16 20:13:07 EST 2013


On 16-01-2013 11:57, Roman Łapacz wrote:

>> * Where does it specify that all NML descriptions should start with
>> nml:Topology as the root element?
> 
> It's not specified. No need.

Should we put this in the document somewhere?

If so, where?


>> * 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.
[...]
>> Instead, I would suggest to use xs:all:

(FYI: xs:all allows any order of the child elements; the current XSD
schema uses xs:sequence which dicates the order).

> In theory the use of xs:all is allowed inside xs.complexType but when I
> run validation for it in this case (based on Xerces) it gets crazy:

Ok.... well, I guess this mostly proves that I am indeed not fluent in
XSD. What I was trying to accomplish is to allow any order of child
elements, and thought that xs:all did the trick.

I actually was inspired by the answes to this post:
http://stackoverflow.com/questions/2290360/xsd-how-to-allow-elements-in-any-order-any-number-of-times


Out of curiousity, what happens in these cases:

(1) Attributes move to the start of the complexType:

>   <xs:complexType name="NetworkObject">
>     <xs:attribute  name="id"       type="xs:anyURI"        use="optional"/>
>     <xs:attribute  name="idRef"    type="xs:anyURI"        use="optional"/>  <!-- referencing and inheritance -->
>     <xs:attribute  name="version"  type="xs:unsignedInt"   use="optional"/>
>     <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: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>
>     </xs:all>
>   </xs:complexType>
> 

(2) attributes part of the group:

>   <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: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>
>       <xs:attribute  name="id"       type="xs:anyURI"        use="optional"/>
>       <xs:attribute  name="idRef"    type="xs:anyURI"        use="optional"/>  <!-- referencing and inheritance -->
>       <xs:attribute  name="version"  type="xs:unsignedInt"   use="optional"/>
>     </xs:all>
>   </xs:complexType>
> 

[..]

> Besides xs:all seems to be very limited. It can not contain xs:group,
> xs:choice, xs:sequence.

That's true for XSD 1.0:
http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/#declare-contentModel

But for XSD 1.1, this limitation is lifted:
http://www.w3.org/TR/2012/REC-xmlschema11-1-20120405/#declare-contentModel

Apparently, Xerces only supports XSD 1.0.




> I updated Relations. Now there is clear distinction between implicit and
> explicit ones.


Ah, After I send this mail, I realized it is possible to eliminate the
difference, and started to become in favour of that solution. :)

I'm curious to your solution. Did you push it to the git repository? I
only see Jeroen's commit of Jan 15 there.




> I keep idRef as we agreed to still support it (as an option; correct me
> if I'm wrong).

It is not mentioned in the document nor OWL schema.

Do you propose to change these documents too, and explicitly allow idRef
with the note that it should be regarded as completely equivalent to id?

I'm fine, but that kind of info ought to be in the document.

Freek


More information about the nml-wg mailing list