You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When xml.Marshal is called on a struct it will happily reflect the information in the
"tag" of an XMLName member regardless of the type to give the struct a
tag-name in it's XML form. This is backed up by the documentation which says:
> The name of that XML element is taken from, in order of preference:
> - the tag on an XMLName field, if the data is a struct
> - the value of an XMLName field of type xml.Name
> ...
However xml.Unmarshal *does* care about the XMLName field being of type xml.Name, and
currently returns the error "field XMLName does not have type xml.Name" if you
have it set to something else.
This is firstly inconsistant with xml.Marshal but it also makes it impossible to use
xml.Marshal alongside other Marshallers (like json/bson) without poluting the state's
namespace with XMLName fields. Inorder to exclude fields from other Marshallers the
convention has been started to tag fields as "omitempty"; which will cause the
field not to display if it is at it's "zero" state, XMLName cannot have such
as zero-state since it is a struct, so it is nicer to use a pointer/bool value for
XMLName so it can be easily excluded when I want to Marshal my struct by some other wire
format.
Attached is the proposed minor change, that simply stops erring if it can't set the name
on the XMLName field, which is just optional metadata anyway.
mikioh
changed the title
Inconsistant XMLName behaviour for xml.Marshal/Unmarshal
encoding/xml: Inconsistent XMLName behaviour for Marshal/Unmarshal
Jan 9, 2015
by chrisfarms:
Attachments:
The text was updated successfully, but these errors were encountered: