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
Currently, an arbitrary Go value marshalled to XML with a (non-local) XML namespace sets the default namespace for its start element and all elements contained within it. For example, a value with local name "foo" in the "bar" namespace would be marshalled as
<foo xmlns="bar"/>
While this leads to succinct XML most of the times, it does not work well with the newly added 1.5 feature to declare custom namespace prefixes: the xml.Encoder marshals the xml prefix declarations but ignores them while marshalling inner XML elements (see the example below).
I propose to make the declaration of default namespaces optional, and activated by default for backward-compatibility. To do so, I outlined a proof of concept in CL 11074.
Example
A value of type
type Foo struct {
XMLName xml.Name `xml:"foons foo"`
Bar string `xml:"barns bar"`
}
encoded with EncodeElement and explicitly declared namespace prefixes "f" for "foons" and "b" for "barns" is currently marshalled as
This proposal was based on the now reverted XML changes for Go 1.5. I might just as well close this issue and abandon the CL. If there is no other feedback, I'll do so tomorrow.
Problem and Proposal
Currently, an arbitrary Go value marshalled to XML with a (non-local) XML namespace sets the default namespace for its start element and all elements contained within it. For example, a value with local name "foo" in the "bar" namespace would be marshalled as
While this leads to succinct XML most of the times, it does not work well with the newly added 1.5 feature to declare custom namespace prefixes: the xml.Encoder marshals the xml prefix declarations but ignores them while marshalling inner XML elements (see the example below).
I propose to make the declaration of default namespaces optional, and activated by default for backward-compatibility. To do so, I outlined a proof of concept in CL 11074.
Example
A value of type
encoded with EncodeElement and explicitly declared namespace prefixes "f" for "foons" and "b" for "barns" is currently marshalled as
whereas the following output might be expected
The text was updated successfully, but these errors were encountered: