New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
encoding/xml: MarshalXML interface is not good enough #2771
Labels
Milestone
Comments
The obvious answer is to add a MarshalXML method to time.Time, like we did for json and gob, but it is not clear to me that the xml package's Marshaler interface is really thought out. It appears to be responsible for including the xml tags <Foo></Foo>, but that means that it cannot be used for attributes, and worse I don't think it has the information available to figure out what tag to use: the field name is unavailable. For Go 1 it is possible that we should remove the xml.Marshaler interface to enable a rethink at a later time. Gustavo? Labels changed: added priority-go1, removed priority-triage. Status changed to Accepted. |
Agreed, I'd prefer to take the interface off as well, and bring it back after Go 1 with a matching unmarshaler interface (which doesn't exist in any style right now). Owner changed to @niemeyer. |
I've just switched to tip. ISTM that this has made things worse. Before I had a Thing struct and a parallel XMLThing struct (with the xml-specific tags). Then I could write the xml.Header and <THINGS> myself, and then convert each Thing to an XMLThing one at a time for writing, finally writing </THINGS> myself. But now that doesn't seem possible so I have to create an entire parallel data structure in memory. However, I guess that once the new xml.Marshaler interface is done, I'll be able to do the conversions on the fly. Also, I notice that the xml.Encoder doesn't support time.Time at all now. |
Issue #4016 has been merged into this issue. |
I have looked around for discussion of design intentions for this issue, but have found nothing except what is here. In the absence of this discussion, I have put together a CL (https://golang.org/cl/7379049/) for xml.Unmarshaler support. This is principally for my own use as a forked package while the standard library does not yet support Unmarshaler, but I figured it may provide some basis for discussion. The CL as it stands does not correctly handle `xml:"A>B"` tags, feeding the entire A element to the Unmarshaler - I have not been able to figure out how to retain the B start offset without becoming horribly tangled. Because of this I have not included tests in the CL. If this is not completely off track I can spend more time on handling sub-elements and submit it for formal review (as it stands it is satisfactory for my use). |
I am sad to say it, but I think we will have to postpone XML work until after Go 1.1. I regret that we didn't have more time to make encoding/xml better, but given the tradeoff I think focusing on core performance and implementation pieces for this final release push is probably the right choice. Unlike most of the performance and other stuff we're trying to shake out right now, functionality such as XML parsing can be provided by go get-able libraries as a stopgap until Go 1.2. More comments specific to CL 7379049 on the CL. Labels changed: added go1.2, removed go1.1. Owner changed to ---. |
This issue was closed by revision 85f3acd. Status changed to Fixed. |
This issue was closed by revision 56ce83f. |
This issue was closed by revision 54bdfc0. |
This issue was closed.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
The text was updated successfully, but these errors were encountered: