Use local name when choosing enum variant based on element name

[adamreichold]

This is consistent to how struct fields are identified in MapAccess::next_key_seed as demonstrated by the two test cases.

[Mingun]

I working on correct deserializing of namespaced names, so this code will still be changed anyway. So it doesn't make much sense to change anything now, but I have no objections to the code

[adamreichold]

I working on correct deserializing of namespaced names, so this code will still be changed anyway. So it doesn't make much sense to change anything now, but I have no objections to the code

I am very happy to here this as we currently need to use a different where namespacing does matter. Thank you for working on it!

However, I do suspect that will involve API changes? Maybe this change could be cherry-picked to be part of a 0.23.x maintenance release? Or do you consider it breaking as well as currently working code (albeit not really since one needs to match on the prefixes, not the namespaces themselves) will stop to do so?

[Mingun]

However, I do suspect that will involve API changes?

Yes, the way how you map fields to XML elements / attributes will be changed to be able to support namespaces regardless of the prefix used.

Maybe this change could be cherry-picked to be part of a 0.23.x maintenance release?

Some of our users depends on the 0.23 version, according to the lib.rs, and this change in a patch could break them (although, the information on that page does not contain a list of the features used, in principle, if we make sure that those dependent on 0.23 do not use the serialize feature, we could merge that to 0.23).

The other way -- we can merge this now and you could temporary depend on the git hash (anyway, master has a some significant improvements in the serde support).

[adamreichold]

If there are reservations, merging it into the main branch seems preferable to me.

[Mingun]

One minor thing -- could you add a changelog entry? Although the implementation will still be changed, it is better that the changelog reflects all current changes if anyone else decides to use master until a release will be made

[adamreichold]

One minor thing -- could you add a changelog entry? Although the implementation will still be changed, it is better that the changelog reflects all current changes if anyone else decides to use master until a release will be made

Added an entry under the "Bug Fixes" heading.