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