Comment 1:

Yeah, and on the same vein it must also handle foo>bar,attr.

Comment 2:

Owner changed to @niemeyer.

Comment 3 by chris.jones.yar:

A common example of this problem is the xml:lang attribute that appears in data formats
like XMPP's stanzas.

Comment 4 by krolaw:

Should foo>bar,attr be listed as a separate bug?  I was bitten by it today.

Comment 5 by chris.jones.yar:

They seem like separate bugs to me. I've started on a fix for this one, and it seems
like it won't fix the other problem.

Comment 6 by krolaw:

Ok, foo>bar,attr bug added - https://golang.org/issue/3688

Comment 7 by BeMasher:

Ran into this issue with atom feeds from the picasa gdata api. The album feed produces
entries with id nodes in the atom namespace and later id nodes in the gphoto namespace. 
With the namespace url being ignored in the field's tag the last decoded id node
regardless of namespace is decoded into it.

Comment 8:

Labels changed: added go1.1maybe.

Comment 9:

Labels changed: removed go1.1maybe.

Comment 10 by robin.gloster:

You can do so by supplying the namespace URL instead of the Prefix:
Content     string   `xml:"http://purl.org/rss/1.0/modules/content/ encoded"`
instead of
Content     string   `xml:"content:encoded"`

Comment 11 by chris.jones.yar:

https://golang.org/cl/6868044 addresses this.

Comment 12:

Labels changed: added size-l.

Comment 13 by sorin.ionescu:

Thank you, Chris, for the https://golang.org/cl/6868044 patch; it looks
promising. We are not there yet. While it can marshal namespaces, it cannot unmarshal
them.

Comment 14 by chris.jones.yar:

Can you expand on that a bit? I'm using this code to marshal and unmarshal XMPP traffic,
which uses namespaces quite a bit.
It's not important to me whether my patch is the one that fixes this bug; I'd just like
to see it fixed. But if nobody else is going to fix it, I'd appreciate an explanation of
what requirements my patch needs to meet in order to be accepted.

Comment 15:

Welcome to "open source". :)

Comment 16:

https://golang.org/cl/7227056/

Comment 17 by cornelius.howl:

https://golang.org/cl/7350048/ Here is a simple patch.

Comment 18:

This issue was closed by revision 4dd3e1e.

Status changed to Fixed.

Comment 19:

CL https://golang.org/cl/6868044 references this issue.