[Nml-wg] Review of the XSD schema

[Roman Łapacz]

W dniu 2013-01-17 02:13, Freek Dijkstra pisze:
> 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?

I don't think so. A subset of nml elements may be used be some 
applications and I can imagine that nml:Topology is not needed.

>
> 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>
>>

Attributes have to be at the end of xs:complexType and can not be 
inside  xs:all


> [..]
>
>> 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.

Yes (for validation I use StdInParse based on Xerces-C++).
We need something for validation. Xerces seems to be the best choice 
(correct me if I'm wrong or you have also a good alternative). We should 
assume that implementations may use automatic schema validation for nml 
structures so we have to run validation with a well-known tool/lib as 
well (and then announce that e.g. the NML schema v1 is validated with 
Xerces).

>
>
>
>
>> 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.

Now it should be there. Please, check it.

>
>
>
>
>> 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?

Yes. I clearly remember that we agreed to keep it. We prefer to use id 
but IdRef for references should be allowed as well.

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

Yes

Roman

>
> Freek