[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