The reason for this relates to restrictions in XML schema. In constructing the mini-schema needed for automated validation, I had to make a choice. In the Why section, Name, Concept, Description, and Reference are allowed only once, but multiple Inferences are allowed. Within a "complex" element such as Why, if any of the children are allowed to appear more than once, the children must be forced to be in a particular order. In XML-speak, if Why is set to unordered ("any") and one or more of the children can appear more than once (MaxOccurs > 1), it is an error "the {max occurs} of all the particles in the {particles} of an all group must be 0 or 1". In plain english, the error says "you can't have any child elements that appear more than once and have the child elements unordered at the same time". I'm confident that there's some logical explanation for this; I don't know it. I leave that to the XML priests.
So in order to do any validation I nad to make the Why section in the mini-schema require ordering of the child elements. What order? In making the mini-schema, I used a year's worth of real VOEvent messages and fed them through the validator, tweaking the schema until I was left with the minimum number of errors. For more info on that process see my IVOA Note Reflections on VOEvent 1.1 and the Real World. In doing this, it was observed that Inference preceded Description in the real world messages.
Unfortunately in the sample given in Sky Event Reporting Metadata (VOEvent) Version 1.11, Section 4.1, Inference follows Description. This is why the sample fails. Moving the Inference section above Description will result in it succeeding.
This is the sort of issue that we really need to get right for VOEvent 2.0. The spec and schema (whichever ends up being normative) must honor standard XML constructions so we don't have this sort of problem. My goal in making the validator tool, the validators in the broker/receiver and publisher, and the online validator, is to raise the level of awareness of XML issues and correctness so that we don't have interop problems due to fast-and-loose XML constructions that end up not being programmatically recognizeable.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The sample VOEvent message in the IVOA Recommendation Sky Event Reporting Metadata (VOEvent) Version 1.11, Section 4.1, fails validation in the online checker and in Dakota Tools.
The reason for this relates to restrictions in XML schema. In constructing the mini-schema needed for automated validation, I had to make a choice. In the Why section, Name, Concept, Description, and Reference are allowed only once, but multiple Inferences are allowed. Within a "complex" element such as Why, if any of the children are allowed to appear more than once, the children must be forced to be in a particular order. In XML-speak, if Why is set to unordered ("any") and one or more of the children can appear more than once (MaxOccurs > 1), it is an error "the {max occurs} of all the particles in the {particles} of an all group must be 0 or 1". In plain english, the error says "you can't have any child elements that appear more than once and have the child elements unordered at the same time". I'm confident that there's some logical explanation for this; I don't know it. I leave that to the XML priests.
So in order to do any validation I nad to make the Why section in the mini-schema require ordering of the child elements. What order? In making the mini-schema, I used a year's worth of real VOEvent messages and fed them through the validator, tweaking the schema until I was left with the minimum number of errors. For more info on that process see my IVOA Note Reflections on VOEvent 1.1 and the Real World. In doing this, it was observed that Inference preceded Description in the real world messages.
Unfortunately in the sample given in Sky Event Reporting Metadata (VOEvent) Version 1.11, Section 4.1, Inference follows Description. This is why the sample fails. Moving the Inference section above Description will result in it succeeding.
This is the sort of issue that we really need to get right for VOEvent 2.0. The spec and schema (whichever ends up being normative) must honor standard XML constructions so we don't have this sort of problem. My goal in making the validator tool, the validators in the broker/receiver and publisher, and the online validator, is to raise the level of awareness of XML issues and correctness so that we don't have interop problems due to fast-and-loose XML constructions that end up not being programmatically recognizeable.