Order of XML elements should not matter

[kaikreuzer]

XML thing/channel types have a couple of properties that are declared in the XML as elements.
Currently, a certain order seems to be expected, this leads to problems like the one that required this patch in order to make the XML parsable. This is imho very unexpected and I do not really see a good reason why it has to be that way.

[svilenvul]

I think the implementation is made this way, because of the thing-description-1.0.0.xsd. The sequence element assumes that an order is expected.

[sjsf]

This is correct. However, it's not that trivial to change the XSD accordingly, as the obvious choice (<xs:any>) does not allow choices inside. So things get pretty messy, considering we need to keep full backward compatibility. But maybe you have a good idea...?

[htreu]

I gave this another try. But as @SJKA already pointed out the xs:choice elements are forbidden inside of xs:any or xs:all. There is however a workaround described here which to some extend is doable. Unfortunately we would loose namespace definitions for channel & config descriptions as they would have to be refactored into separate XSDs without namespace.

Otherwise all types now provided in xs:choice elements would need to be refactored to also carry the thing-description namespace like

<thing-type id="myId">
	<label>My Thing</label>
	<thing:channels>
		<channel id="switch" typeId="switch" />
	</thing:channels>
	<thing:config-description>
		<parameter type="text" name="test">
		</parameter>
	</thing:config-description>
</thing-type>

This way everything could stay in the same XML, the solution above is achieved using the xs:element abstract="true" and xs:element substitutionGroup="...".

Imho this is too much of an effort just to be order independent. My Suggestion is to label this issue as "Wont Fix" and reference it whenever needed.

[triller-telekom]

I agree that this is too much effort and also we would need to change all existing bindings because of the added namespace to the elements. Maybe if we have to break the API some day anyway we could think of it. But now just to ignore the order of elements it is IMHO not worth it.

@SJKA @kaikreuzer Can you please clsoe this issue as @htreu suggested with "won't fix" label?

[kaikreuzer]

I don't like it, but what is there to do...