Understanding Generation Bug - xs:Sequence order with FSM

[aitee]

I'm trying to understand is why the schema order isn't being respected when adding a new (and first) object whose type is defined within a sequence. For simple handwritten schemas the order is respected (and the generated code is quite a bit different).

In a schema xsd, when I have sequence:
https://github.com/com-pas/compas-scl-xsd/blob/develop/src/main/resources/xsd/SCL2007B/SCL_IED.xsd#L323 (DataSet comes before DOI)
https://github.com/com-pas/compas-scl-xsd/blob/develop/src/main/resources/xsd/SCL2007B/SCL_IED.xsd#L365 (GSEControl comes before SettingControl, but after DataSet)

Is it expected to have a contentModel assignment (contentModel = new SequenceContentModelEntity) in the static constructor (this is what I see in the handwritten/simple schema)? But for complex schemas, I instead see InitFSM() in its place.

Is this InitFSM() code expected to handle order when setting an object that isn't yet represented in the XML DOM (i.e. a new object that needs to be placed based on the sequence order defined in the schema)?

I am using XObjects Core version 3.3.0 (because I have been having other issues with later versions).

Any insight on how/when contentModel is generated versus the InitFSM case and how their responsibilities relate to ordering objects added would help me better understand where the issue could lie.

Thanks!

[aitee]

It seems like the FSM codepath is intended to set objects based upon the schema, but doesn't work when setting an object which doesn't exist in the DOM already:

It seems like it just appends it to the parent rather than accounting for the sequence which should define how the siblings are ordered.

Items getting added into the wrong order also causes properties which are not backed by a field (only a getter and setter to the DOM) to have strange behaviors. For instance:

if (nonNullObj.PropList == null)
{
    nonNullObj.PropList  = new tProp();
}

// Code expects nonNullObj.PropList to be non-null...
// But it is actually null because of another sibling being out of order.
// This out of order element causes the FSMGet to return null for the nonNullObj.PropList access (despite it being in the DOM)
nonNullObj.PropList.Add(...)

I know I'm not on the latest, but the code appears to be the same at the tip of master.

[mamift]

Hello, thank you for logging this; I hope to begin a bug fix sprint for LinqToXsdCore sometime soon and hope to include this issue in the fix. Do you know if those SCL_IED XSD files are freely available under a permissive license?

[aitee]

First off, I am not a lawyer.

IEC Substation Configuration Language (SCL) is not released under an open-source license—it is part of the official IEC 61850 standard, which is copyrighted and licensed by the International Electrotechnical Commission (IEC).

A few potential options:

1. Locally use the XSD files to validate an SCD -- Understand the issue to then recreate a toy example that demonstrates the problem.
2. Understand the IEC licensing requirements (seems they typically allow for engineering and implementation but not redistribution). Seems possible -- but I am not a lawyer.

If you ended up going with option 1, I believe I could get the SCL file that fits the schema -- but it has been a while since I've been working on this particular item and may be a while for me to dig it up.