[Ext] Re: [xsd-users] DLLs and --generate-element-type --generate-element-map

[Nicolas Weidmann]

Hi Boris,

In order to make life more simpler for me, I am planning to write a small app that will scan the XSDs for root elements and will create the helpers I need based on the different parseMyObject / serializeMyObject.

Regards,


Nicolas Weidmann
Banque Lombard Odier & Cie SA
Rue de la Corraterie 11 - 1204 Genève - Suisse
T +41 22 709 23 17
www.lombardodier.com
-----Original Message-----
From: Nicolas Weidmann
Sent: mardi, 14 juillet 2026 15:32
To: xsd-users at codesynthesis.com
Subject: RE: [Ext] Re: [xsd-users] DLLs and --generate-element-type --generate-element-map

Hi Boris,

Thanks for your reply.

The reason I was willing to use element types is the single parse/serialize

We have a library that embeds XMLs into something, but this library has no clue about its input.

It just wants to serialize its input.

Without --generate-element-type --generate-element-map, I get parseFidget / serializeFidget

With those functions, I have no issues with polymorphism, but they are not generic.

This means that we will have to write custom parse / serialize for every root element of all our data-bindings.

Parsing is less an issue, but the lack of generic serialization will be as we have a lot of root elements throughout our data-bindings.

A ADL serialize for a future release of XSD ?
Or parse/serialize traits ?

Regards,


Nicolas Weidmann
Banque Lombard Odier & Cie SA
Rue de la Corraterie 11 - 1204 Genève - Suisse
T +41 22 709 23 17
www.lombardodier.com
-----Original Message-----
From: Boris Kolpackov <boris at codesynthesis.com>
Sent: mardi, 14 juillet 2026 14:28
To: Nicolas Weidmann <n.weidmann at lombardodier.com>
Cc: xsd-users at codesynthesis.com
Subject: Re: [Ext] Re: [xsd-users] DLLs and --generate-element-type --generate-element-map

Hi Nicolas,

Nicolas Weidmann <n.weidmann at lombardodier.com> writes:

> And the second document that fails (parses only the Fidget part, not the
> SubFidget...)

Yes, because, as mentioned in my followup email, the element type feature
does not handle polymorphism (xsi:type in your case).

The further point I was trying to make in that email is that element
types/map are rarely useful with polymorphic root elements and your
test case matches this assessment since you only have one element.

I think the only sensible way forward is to stop using element types.
In the example that you have shown you just as easily can use the
Fidget type since there is a 1:1 mapping between Fidget and AcmeProduct.
It should still be easy enough to handle if you have a handful of
elements like AcmeProduct (note: elements that are part of substitution
groups don't count, only "true" roots of hierarchies). Admittedly it
will become problematic if you have a large number of "true" roots
like AcmeProduct.
[[ rethink everything. ]]<https://www.lombardodier.com>

[[LinkedIn]]<https://www.linkedin.com/company/lombard-odier>  [[Twitter]] <https://twitter.com/lombardodier>   [[Facebook]] <https://facebook.com/lombardodier>   [[Instagram]] <https://www.instagram.com/lombardodier/>   [[YouTube]] <https://www.youtube.com/channel/UCqatbeqXskmWejbm0KPLV3w>

*** IMPORTANT NOTICE REGARDING INSTRUCTIONS by EMAIL ***
Please be aware that instructions received by e-mail should be
considered delayed and not executed unless they have been
specifically confirmed by your relationship manager/banker.
Email traffic during turbulent times in the financial markets is
high and cannot always be acted upon at all times.
Lombard Odier cannot be held liable for such delay in execution
or for the non-execution of an instruction given by email even
if it was given in due time. Therefore, instructions requiring
immediate action must be communicated by telephone by calling
the bank’s registered landline.
Thank you for your understanding.

*** IMPORTANT INFORMATION ABOUT DATA PROTECTION ***
You might be receiving this because you have provided us with
your contact details. If this is the case note that we may process
your personal data for direct marketing purposes.
If you wish to object to this processing, please notify the
Group’s Data Protection Officer<mailto:group-dataprotection at lombardodier.com>.
For more information: www.lombardodier.com/privacy-policy

DISCLAIMER **********************************************
This message is intended only for use by the person
to whom it is addressed. It may contain information
that is privileged and confidential. Its content does
not constitute a formal commitment by any company
of the Lombard Odier group. If you are not the intended
recipient of this message, kindly notify the sender
immediately and destroy this message. Thank You.
*******************************************************(dch)*