Implement quickxml support

[matzipan]

Hi,

I'm not sure if quick-xml/serde support is something that you are interested in upstream. Just wanted to open this MR to show some of the early work that I am doing to create serde/quick-xml compatible type definitions. Feel free to close this merge request if it's not a direction that you want to take.

quick-xml of course does not support namespaces so for now I just nerfed the definition and just ignored the parameter.

One change which is not strictly related is a64a146. The reason for this is that you can have a lot of nouns with irregular plural like matrix -> matrices, so adding "s" is not the best default to have. I can submit this as a separate MR if it's interesting upstream.

So far I was able to parse XMLs with these descriptions: ttps://sanaregistry.org/files/ndmxml_unqualified/ndmxml-3.0.0-omm-3.0.xsd and ttps://sanaregistry.org/files/ndmxml_unqualified/ndmxml-3.0.0-common-3.0.xsd The parsing has been partial due to some missing things like group, and possible choice so I have to look at that next.

[MarcAntoine-Arnaud]

Hi @matzipan

I have look your PR.

It's a great work.
I think for a64a146, it maybe great to push it with an another MR as yo suggested.

For the support of quick-xml, I'm not opposite.
The only problem I see with your MR is you replace yaserde by quick-xml/serde.
I think the right way is to support multi xml serde engine, and features are made for that.

So my suggestion is to create features in xml-schema named yaserde and quick-xml or serde (does serde may use various xml serde crates ?)
And based on the feature it has to drive the derive code generation.

Does it make sense for you ?
Like that we can continue to support YaSerDe but also support quick-xml/serde.

[matzipan]

I think the right way is to support multi xml serde engine, and features are made for that.

So my suggestion is to create features in xml-schema named yaserde and quick-xml or serde (does serde may use various xml serde crates ?) And based on the feature it has to drive the derive code generation.

Does it make sense for you ? Like that we can continue to support YaSerDe but also support quick-xml/serde.

Makes sense.