Incorrect SSD xml syntax parsing due to element order ("element 'ParameterBindings' is not allowed for content model")

[GorbadPS3]

Description

It appears the order of XML elements in the SSD file matters for the XML validation parser. I have two identical .ssp models:

models_here.zip

The only difference in them is the .ssd file inside, where in the "works.ssp" we have a ParameterBindings object at the top:

<ssd:System name="Root">
  <ssd:ParameterBindings>
    <ssd:ParameterBinding source="resources/52fa3348-3287-4807-a940-dd1108feebdb.ssv"/>
  </ssd:ParameterBindings>
  (the rest of the System xml) 
</ssd:System>

While in the error.ssp, we have it at the end:

<ssd:System name="Root">
  (the rest of the System xml) 
  <ssd:ParameterBindings>
    <ssd:ParameterBinding source="resources/52fa3348-3287-4807-a940-dd1108feebdb.ssv"/>
  </ssd:ParameterBindings>
</ssd:System>

We're seeing the following validation error:

warning: invalid "SystemStructureDescription" detected in file "error.ssp" at line: 601 column: 18, element 'ParameterBindings' is not allowed for content model '(Connectors?,ElementGeometry?,ParameterBindings?,Elements?,Connections?,SignalDictionaries?,SystemGeometry?,GraphicalElements?,Annotations?)' warning: "SystemStructureDescription" does not conform to the SSP standard schema

From XML specifications: Generally speaking, the order in which child elements appear inside their parent element container in XML shouldn't matter

I believe OMSimulator's xml validator should not print warnings in the console (and possibly ignore content) if the order is different. After all, XML generally speaking allows elements to appear in any order.

Steps to reproduce the behavior

Run:

OMSimulator.exe --startTime=0.0 --stopTime=0.1 works.ssp

And:

OMSimulator.exe --startTime=0.0 --stopTime=0.1 error.ssp

(note: You can ignore the calculation errors of the simulation models provided: They are dummy FMU models)

You'll notice that for the "error.ssp" OMSimulator warns about the ParameterBindings, but not for the "works.ssp".

Expected behavior

The parsing of the XML should not warn about invalid elements if they appear in a different order.

Version and OS

OMSimulator.exe --version OMSimulator v2.1.2.post6-g637a1c9-win-notlm

OS: Windows 11, 64-bit.

[arun3688]

@GorbadPS3 The schema is validated against SSP specification 1.0, We earlier supported different ordering of SSD elements, but then our ssp's do not load in https://www.easy-ssp.com/ tool, So currently the ssp's are validated according to SSP specification 1.0 and we generate only warnings and still the simulation continues. So the validation is done according to schema in https://github.com/modelica/ssp-standard

[GorbadPS3]

Hi @arun3688 , I don't understand where in the Schema it says the ParameterBindings must come first? Or where the order is mentioned?

[arun3688]

@GorbadPS3 The ssp are validated according to the schema provided by standard https://github.com/modelica/ssp-standard/tree/main/schema, you can look into this and also for .ssd the schema file you can see here https://github.com/modelica/ssp-standard/blob/main/schema/SystemStructureDescription.xsd

[GorbadPS3]

Right, so if I understand this correctly, TSystem's base TElements takes priority in the order:

		Connectors
		ElementGeometry
		ParameterBindings
		Elements
		Connections
		SignalDictionaries                    
		SystemGeometry
		GraphicalElements
		Annotations

Thus this would be the order of elements within a TSystem in the xml.