CoSimualation (misspelling) causes exception

[CThuleHansen]

Checking XML
Exception: XML validation: org.xml.sax.SAXParseException; systemId: file:/tmp/xml115948.xml; lineNumber: 18; columnNumber: 47; cvc-complex-type.2.4.a: Invalid content was found starting with element 'CoSimualation'. One of '{ModelExchange, CoSimulation, UnitDefinitions, TypeDefinitions, LogCategories, DefaultExperiment, VendorAnnotations, ModelVariables}' is expected.
Problem converting XML to VDM-SL?

I understand the problem, but the reporting of this error is very different than the "regular" reporting of errors.
So I am thinking that this should be converted to the "normal" error reporting similar to

Checking XML
	1306: 2.2.7 Variable "v1" causality/variability/initial/start <input>/<continuous>/nil/nil invalid at line 6
	1305: 2.2.7 ScalarVariable "v1" invalid at line 6
	1009: 2.2.1 ScalarVariables invalid
	Errors found.

?

[nickbattle]

Yeah, it is a bit ugly. This is the XSD validation exception format. The problem is, I don't know the full set of exception messages I can get, so it's difficult to pick out the important bits to create a simpler error in general. If I just turn these into "XML validation failed" that would be useless.

I'll try to find out whether the errors are actually more structured and predictable than they appear.

[nickbattle]

Just to confirm, this is the same in the 1.1.3 VDMCheck tools, for much the same reason.

/home/nick> VDMCheck2.sh minimal.xml
Internal 0000: Cannot read file: XML validation: org.xml.sax.SAXParseException; systemId: file:/home/nick/minimal.xml; lineNumber: 4; columnNumber: 46; cvc-complex-type.2.4.a: Invalid content was found starting with element 'CoSimualation'. One of '{ModelExchange, CoSimulation, UnitDefinitions, TypeDefinitions, LogCategories, DefaultExperiment, VendorAnnotations, ModelVariables}' is expected.

So currently, the FMI checking assumes that the input is a valid XML document according to the XSD. It does check this, but the error you get is "internal" - ie. fundamental.

I'll see whether we can be smarter about this...

[nickbattle]

So it looks like I could avoid the location details (though that is important), but otherwise the validation error is just an unstructured string, in this case:

cvc-complex-type.2.4.a: Invalid content was found starting with element 'CoSimualation'. One of '{ModelExchange, CoSimulation, UnitDefinitions, TypeDefinitions, LogCategories, DefaultExperiment, VendorAnnotations, ModelVariables}' is expected.

[CThuleHansen]

Hmm I actually did run with 1.1.3 after the snapshot, but I must have stared myself blind (does that expression work in English as well?) and somehow did not notice the "internal error" marking that was added to 1.1.3. I think the internal error is fine. Don't remove the location 🙂

The different format makes it seem like it is a "tool" mistake, which it certainly is not.
From a person validating a modeldescription.xml file it is just a valid mistake as the other ones.

But honestly, it is a small thing.

[CThuleHansen]

It also seems like this kind of error does not cause an exit code?

[CThuleHansen]

So to summarize -
I understand that this kind of error is structural, whereas the other is semantic.
But from the perspective of verifying a modeldescription file, both are errors.

So I think the script should have an non-zero exit code and still have the "Errors Found" on both occasions

[nickbattle]

I agree that it really ought to say "Errors Found" and have an exit code. That should be easy to fix. I'm currently working on 1.1.4-SNAPSHOT.

And "stared myself blind" does work in English, yes!

[nickbattle]

This turns out to be quite a subtle problem. The VDMJ evaluation returns "true" or "false" as the overall result, and this is produced on stdout. But any error messages from @OnFail are also produced on stdout. So the VDMCheck scripts awk the output looking for ^true$ or ^false$. But when the VDMJ evaluation raises an exception, neither result is produced! That is why it says neither "No errors found" nor "Errors found".

The exception comes from the FMUReader, which is a VDMJ adapter that "opens" an FMU or XML file and produces a VDM-SL version of its contents. So I think, rather than complicating the scripts, the easiest way out of the will be to catch the validation error inside the FMUReader and use that to generate VDM-SL which contains an error indicator. Then the VDM validation function can test that flag and fail (return false) in the usual way, which should then treat these errors the same way as logical rule failures.

[nickbattle]

Phew! Well, that was trickier than I thought, but I think it's a good solution. The FMUReader now creates a validationError field in the VDM-SL returned, which is either null or a string of the error found. The VDM validation functions check this and return "false" if the error is set (as well as printing the error). So this now behaves much like other errors.

/home/nick> VDMCheck2.sh minimal.xml
"XML validation: org.xml.sax.SAXParseException; systemId: file:/home/nick/minimal.xml; lineNumber: 4; columnNumber: 46; cvc-complex-type.2.4.a: Invalid content was found starting with element 'CoSimualation'. One of '{ModelExchange, CoSimulation, UnitDefinitions, TypeDefinitions, LogCategories, DefaultExperiment, VendorAnnotations, ModelVariables}' is expected."
Errors found.

The change is pushed to 1.1.4-SNAPSHOT.

[nickbattle]

Can we close this one now?