Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement quickxml support #31

Open
wants to merge 11 commits into
base: main
Choose a base branch
from

Conversation

matzipan
Copy link
Contributor

@matzipan matzipan commented Dec 21, 2023

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
Copy link
Contributor

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
Copy link
Contributor Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants