XML wire format missing for Configuration.ImageFiles / Configuration.PowerSource

[ottobolyos]

Summary

Configuration.ImageFiles and Configuration.PowerSource (both existing model properties — see libraries/MTConnect.NET-Common/Devices/Configurations/Configuration.g.cs) have no XML serialization surrogate. XmlConfiguration (libraries/MTConnect.NET-XML/Devices/XmlConfiguration.cs) declares [XmlElement]/[XmlArray] slots for every other standard AbstractConfiguration substitution-group child — CoordinateSystems, Motion, Relationships, SensorConfiguration, SolidModel, Specifications — but not ImageFiles or PowerSource, even though both are cited in the MTConnect v2.7 MTConnectDevices_2.7.xsd ComponentConfigurationType substitution-group list alongside the others.

There is no XmlImageFile or XmlPowerSource surrogate class anywhere in the repository — this is a complete gap, not a partial one.

Impact

• Read path: an <ImageFiles> or <PowerSource> element inside <Configuration> was previously silently dropped by the plain XmlSerializer (no [XmlAnyElement] catch-all existed). As of PR feat(common): add IConfiguration.VendorExtensions for XSD extension #223 (feat(common): add IConfiguration.VendorExtensions for XSD extension), which added an [XmlAnyElement] capture-all for genuine vendor extensions, these two standard elements are now captured into Configuration.VendorExtensions instead — mislabeling standard MTConnect content as a vendor extension. Configuration.ImageFiles/Configuration.PowerSource remain null either way.
• Write path: Configuration.ImageFiles/Configuration.PowerSource are never emitted to XML at all, regardless of whether they're populated on the model.

Suggested fix

Add XmlImageFile/XmlImageFileDescriptions and XmlPowerSource/XmlPowerSourceDescriptions/XmlPowerSourceType surrogate classes (mirroring the existing XmlSensorConfiguration/XmlSolidModel pattern) and wire them into XmlConfiguration.ToConfiguration() / XmlConfiguration.WriteXml() with [XmlArray("ImageFiles")] / [XmlElement("PowerSource")] slots, ordered before the VendorExtensions capture-all so they no longer fall through to it.

Provenance

Surfaced by the bug-detector pass of the dime review cycle on PR #223 (2026-08-25). Pre-existing gap — not introduced by that PR — scoped out of it as a distinct, non-trivial feature addition (new XML surrogate types for two element families that have never had wire-format support) rather than the VendorExtensions mechanism itself.