Apparently our element types feature is incompatible with polymorphism. We should either fix this or issue an error if a polymorphic type is used for a root element (though with --generate-polymorphic-all it should probably be a warning).
For background, see this mailing list thread that starts here: https://www.codesynthesis.com/pipermail/xsd-users/2026-July/005334.html
If we decide to support this, we will need to fix both parsing and serialization, naturally. Also, substitution group support could get messy. Specifically, the user may request generation of element types for members (as opposed to only roots) of substitution groups, which probably doesn't make much sense (unless they want to be able to enforce "starts from this point in the hierarchy" kind of constraint). Presumably we have the same/similar problem with ordinary parsing/serialization functions so should probably do alike.
Apparently our element types feature is incompatible with polymorphism. We should either fix this or issue an error if a polymorphic type is used for a root element (though with
--generate-polymorphic-allit should probably be a warning).For background, see this mailing list thread that starts here: https://www.codesynthesis.com/pipermail/xsd-users/2026-July/005334.html
If we decide to support this, we will need to fix both parsing and serialization, naturally. Also, substitution group support could get messy. Specifically, the user may request generation of element types for members (as opposed to only roots) of substitution groups, which probably doesn't make much sense (unless they want to be able to enforce "starts from this point in the hierarchy" kind of constraint). Presumably we have the same/similar problem with ordinary parsing/serialization functions so should probably do alike.