encoding/xml: missing nested namespace not handled

[anacrolix]

Nested XML namespaces aren't marshalled correctly. Setting an element namespace at the
default level as Go does, implicitly sets nested elements to the same namespace if they
don't override it.

<a xmlns="b"><c/></a>

The namespace of c, is b. However marshalling from Go data structures in which the
object corresponding to c above has no namespace set should give

<a xmlns="b"><c xmlns=""/></a>

The usual way to deal with this is to use namespace prefixes, but I don't think that's a
requirement.

[davecheney]

Comment 1:

@anacrolix could you please include a short code sample or a test that demonstrates the
issue.

Status changed to WaitingForReply.

[anacrolix]

Comment 2:

Will do.

[anacrolix]

Comment 3:

I've created an example: http://play.golang.org/p/5zDgqtC3ra
The output is currently:
2009/11/10 23:00:00 "b" == "b"
2009/11/10 23:00:00 "" == ""
2009/11/10 23:00:00 "<A xmlns=\"b\"><C></C></A>" != "<A
xmlns=\"b\"><C xmlns=\"\"></C></A>"
2009/11/10 23:00:00 "b" == "b"
2009/11/10 23:00:00 "b" != ""
If you read the play source, you'll observe that the namespace of "" on element C has
been lost when marshalling. When unmarshalling what Go currently produces, it no longer
has "" for C's namespace as a result.
This is incorrect, see:
http://stackoverflow.com/questions/2193220/xml-namespace-defaulting-inheritance
http://www.w3.org/TR/REC-xml-names/#scoping-defaulting
http://www.w3.org/TR/xml-names/#defaulting
The impact this has on programs using XML, is that they don't reset the default
namespace for nested elements when marshalling.
Here's some downstream bugs that result from this:
https://bitbucket.org/anacrolix/dms/issue/25/get-soap-responses-to-work-with-upnp
https://bitbucket.org/anacrolix/dms/issue/19/samsung-doesnt-like-response-to

[anacrolix]

Comment 4:

https://golang.org/cl/66850043/

[rsc]

Comment 5:

Labels changed: added release-go1.3maybe.

Status changed to Accepted.

[gopherbot]

Comment 6:

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

[rsc]

Comment 7:

Alternate CL at https://golang.org/cl/93320043. Leaving final decision for 1.4.

Labels changed: added release-go1.4, removed release-go1.3maybe.

[gopherbot]

Comment 8 by glen.newton:

Is this related to or the same bug as: 'Golang XML unmarshalling issue: local name
collisions fail'
https://stackoverflow.com/questions/24870309/golang-xml-unmarshalling-issue-local-name-collisions-fail/
I am asking as I am trying to figure out if I should submit a bug for my issue.

[anacrolix]

Comment 9:

I don't believe it is the same bug. It could be related, but I recommend you create a
new issue for it.

[griesemer]

Comment 10:

Labels changed: added repo-main.

[rsc]

Comment 11:

We didn't get to this in time. My apologies.

Labels changed: added release-go1.5, removed release-go1.4.