proposal: encoding/xml: add RawXML token #26756
Comments
|
Change https://golang.org/cl/127435 mentions this issue: |
|
cc @rogpeppe |
|
@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. |
|
@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. |
|
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 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. |
mvdan
changed the title
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. |
|
That being said, having a milestone, a label, and a prefix seems like overkill, now that I think about it. |
|
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. |
|
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! |
rsc
changed the title
|
Proposal is similar to #6825 |
|
Change https://golang.org/cl/132836 mentions this issue: |
See golang/go#26756 Change-Id: I6a2b2fae94d71a784a2489e0af8ca2df4b57bc4c Reviewed-on: https://go-review.googlesource.com/132836 Reviewed-by: Ian Lance Taylor <iant@golang.org>
|
On hold for XML sweep. |
|
@rsc Is there any news about the XML sweep? We could really use the functionality listed in this proposal right about now, heh. |
|
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: |
|
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 |
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".EncodeTokenmethod 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,innerxmltag 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&amp;).This is similar in spirit to the known safe types in the
html/templatepackage (eg.HTMLorJS).Proposal: https://golang.org/design/26756-rawxml-token
The text was updated successfully, but these errors were encountered: