proposal: encoding/xml: add RawXML token

[SamWhited]

I have recently been experimenting with writing an XML encoder that (given a struct or other similar type) emits xml.Token's instead of bytes. In doing so I discovered that some XML could be encoded using structs that cannot currently be encoded using the "Encoder".EncodeToken method and that I couldn't finish my project without occasionally switching over to the struct based API. There is currently no equivalent in the SAX-like API for the ,innerxml tag on struct fields. This is useful as it both lets us encode invalid XML (which is unfortunately quite common, and it may be desirable to let Go's encoder work with broken XML encoders and decoders in the wild), and lets us encode pre-escaped XML without accidentally double-escaping (eg. if we know we already have valid XML such as & we can prevent it from being turned into &).
This is similar in spirit to the known safe types in the html/template package (eg. HTML or JS).

Proposal: https://golang.org/design/26756-rawxml-token

[gopherbot]

Change https://golang.org/cl/127435 mentions this issue: encoding/xml: add RawXML token type and tests

[mvdan]

cc @rogpeppe

[mvdan]

@SamWhited have you considered making this a proposal? I'd assume that is the best approach if you want to add new APIs to a stable std package.

[SamWhited]

@mvdan I'm never really sure what the criteria for needing a full proposal are. This seemed straight forward enough to not require one (there's only one way that I can see to do this which is to add a new token type), but I'm also happy to write more about it.

[mvdan]

In this specific case I'd make it a proposal so that the proposal review committee makes a decision on it in the next few weeks. Otherwise, this issue might not get a decision for a while, as NeedsDecision issues are quite common.

I just noticed that you already added this issue to the proposal milestone. I'll add a prefix to the title, which is the better way to make it a proposal :) @gopherbot then takes care of the milestone and label for us.

[SamWhited]

I just noticed that you already added this issue to the proposal milestone. I'll add a prefix to the title, which is the better way to make it a proposal :) @gopherbot then takes care of the milestone and label for us.

Ah thanks, the gardening and issue pages no longer mention the proposal prefix at all that I could find, so I assumed it was deprecated. I think I've been doing this wrong elsewhere too.

[SamWhited]

That being said, having a milestone, a label, and a prefix seems like overkill, now that I think about it.

[mvdan]

Maybe so :) send an email to golang-dev? Maybe the prefix is needed for a specific reason that I'm not aware of. Or perhaps, like you say, we should get rid of it.

The label does seem unnecessary given the milestone, though. I'm just following what pretty much all the other proposals do.

[SamWhited]

Yah, might be worth discussing in any case. If I get around to it later I'll send an email (and start writing up a more formal proposal for this). Thanks for the feedback!

[iwdgo]

Proposal is similar to #6825

[gopherbot]

Change https://golang.org/cl/132836 mentions this issue: design: add raw xml token proposal

[rsc]

On hold for XML sweep.

[BenjaminNolan]

@rsc Is there any news about the XML sweep? We could really use the functionality listed in this proposal right about now, heh.

[nemith]

Ping again. This would solve some corner cases that are hard to solve in the current xml and is related to my very first issue in 2013 which i am still running into today:

#6896

[macdabby]

Any update on this? Looks like there is a PR. It's simple but old enough to have merge conflicts. https://go-review.googlesource.com/c/go/+/127435