encoding/xml: allow mismatched XMLName / field metadata tag names
#48450
Conversation
Currently, if you have nested structs, where the inner struct’s
XMLName doesn’t match the outer struct’s field name metadata, such as:
type InnerStruct struct {
XMLName Name `xml:"innerStruct"`
Name string `xml:"name"`
}
type Outer struct {
XMLName Name `xml:"outer"`
Inner *InnerStruct `xml:"inner"`
}
Then decoding XML produces an error:
xml: name "inner" in tag of xml.Outer.Inner conflicts with name "innerStruct" in *xml.InnerStruct.XMLName
This causes issues when interacting with SOAP web services, whose
WSDLs are expressed with XSD. XSD allows defining reusable types;
each of those types has a unique name. That name MAY be the name of
the tag containing the struct’s data, but isn’t ALWAYS. An
xsd:element may specify a different tag name to contain an XSD type’s
values. An illustration of a real-world case where this happens is
hooklift/gowsdl#219.
This PR uses the big hammer of removing the tests and errors which
cause the issue. I’m reasonably certain that the structFieldInfo()
changes are fine, but I feel less good about Decoder.unmarshal().
Ideally, that code would look at the field metadata of the containing
struct, then the XMLName of the destination struct. I’m not familiar
with this code, but it looks like the parent element isn’t accessible
at the time when this check would need to happen, so I opted to remove
it instead.
fixes hooklift/gowsdl#219
|
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here with What to do if you already signed the CLAIndividual signers
Corporate signers
ℹ️ Googlers: Go here for more info. |
google-cla
bot
added
the
cla: no
|
@googlebot I signed it! |
google-cla
bot
added
cla: yes
|
This PR (HEAD: 22d97c4) has been imported to Gerrit for code review. Please visit https://go-review.googlesource.com/c/go/+/353394 to see it. Tip: You can toggle comments from me using the |
|
Message from Go Bot: Patch Set 1: Congratulations on opening your first change. Thank you for your contribution! Next steps: Most changes in the Go project go through a few rounds of revision. This can be During May-July and Nov-Jan the Go project is in a code freeze, during which Please don’t reply on this GitHub thread. Visit golang.org/cl/353394. |
|
welp |
Currently, if you have nested structs, where the inner struct’s
XMLName doesn’t match the outer struct’s field name metadata, such as:
Then decoding XML produces an error:
This causes issues when interacting with SOAP web services, whose
WSDLs are expressed with XSD. XSD allows defining reusable types;
each of those types has a unique name. That name MAY be the name of
the tag containing the struct’s data, but isn’t ALWAYS. An
xsd:element may specify a different tag name to contain an XSD type’s
values. An illustration of a real-world case where this happens is
hooklift/gowsdl#219.
This PR uses the big hammer of removing the tests and errors which
cause the issue. I’m reasonably certain that the structFieldInfo()
changes are fine, but I feel less good about Decoder.unmarshal().
Ideally, that code would look at the field metadata of the containing
struct, then the XMLName of the destination struct. I’m not familiar
with this code, but it looks like the parent element isn’t accessible
at the time when this check would need to happen, so I opted to remove
it instead.
fixes hooklift/gowsdl#219