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
proposal: encoding/xml: support *string for innerxml in Unmarshal #26512
Comments
Do you have some example real-world XML APIs that require this distinction? It's not obvious to me whether this sort of distinction is idiomatic in XML in general: if it is, we should consider supporting it, but we shouldn't add more decisions for Go users to make if those features aren't portable to other XML parsers anyway. |
Hi @bcmills sorry for the delay. You can refer to this rfc https://tools.ietf.org/html/rfc6241#page-20 This describes a valid document for the use case above. See below for valid documents:
Above shows a document with a filter including a containment, in this case beginning with the element top, note there are lots of valid sub-elements, no rules other than this is innerxml can be inferred.
In the above case the empty filter with no containment, note the whitespace. Ideally I could decode this into a struct type Filter struct {
XMLName xml.Name `xml:"filter,omitempty" json:"filter,omitempty"`
Type string `xml:"type,attr" json:"type,omitempty"`
Containment *string `xml:",innerxml" json:",omitempty"`
} A nil check on the string pointer would allow me to rationalise that no Containment was set. Does this make sense? |
I understand the syntactic difference. My question is, are there real-world APIs for which this is also a semantic difference? The Go Without the pointer-to- <filter type="subtree" /> and <filter type="subtree"></filter> is important? |
Yes, I too am confused about when |
On hold for XML sweep. |
Timed out in state WaitingForInfo. Closing. (I am just a bot, though. Please speak up if this is a mistake or you have the requested information.) |
@seankhliao it seems like this shouldn't have been swept by @gopherbot. Also curious on if there are any plans of an xml sweep (or maybe tasks that should be tagged accordingly) |
There are unanswered questions earlier, and there is no clear proposal as far as I can see. The XML support is unfortunately languishing. |
I would like the contributors to consider extending the xml Unmarshal to support Unmarshalling a innerxml to a *string.
Currently
func Unmarshal(data []byte, v interface{}) error
decodes an xml element into a innerxml as a []byte or string, trying to decode to a *string results in nil as seen below.https://play.golang.org/p/oaGu0rKYNgi
The motivation for this is supporting use cases where both empty and 'not set' semantics are required. This is described well in this article https://willnorris.com/2014/05/go-rest-apis-and-pointers#pointers
Thanks in advance,
Damian.
The text was updated successfully, but these errors were encountered: