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: foo>bar,attr - foo ignored #3688
Comments
Labels changed: added priority-soon, removed priority-triage. Owner changed to builder@golang.org. Status changed to Accepted. |
Here's a better example: http://play.golang.org/p/VrtQ0GSF1v |
This is an interesting "bug" .... I agree, the status does need to be updated. WaitingForReply is certainly incorrect. In the above examples, this can be 'fixed' by slightly changing the data definitions. See: http://play.golang.org/p/VE74VQoJ7c The == comparison still fails. As it should. But actual results on Unmarshal and MarshalIndent seem to be correct by visual inspection. |
Your fix was helpful to me, and my example needs more work. Suggestions welcome. However, it would be great if the xml package was consistent with elements and attributes, for example: root>data>value works for <root><data><value>tada</value></data></root> root>data>value,attr should imho work for <root><data value="tada"/></root> It would mean you wouldn't need to create struct stepping stones to the attribute. |
I am glad you found that useful. Using == to compare results seems .... perhaps not the best approach given output from my example above. Note however, that the == comparison should show true if you add </getBookings> to the raw input properly. Should the xml package handle your original input? My current thinking is: yes. But if it will not or can not, then that behavior needs to be somehow documented at least. The source for the xml package is a bit daunting. To me anyway. In particular note the one big BUG comment by rsc in read.go. That makes it very unclear to me what the go team is thinking in regards to the package as a whole. Good luck with this. |
Here's a better test: http://play.golang.org/p/KN6MWrvFJD It compares the xml output of both our structs, which should be identical. |
Nice. However ..... After thinking / reading more I am not convinced that what you are seeing is totally incorrect. The godoc for the xml packages says (in several different places): <godoc> a non-pointer anonymous struct field is handled as if the fields of its value were part of the outer struct. </godoc> I now think that has something to do with what you are seeing. I originally thought this was a problem with Unmarshal, and if that could be corrected then Marshal would behave as might be expected. That was incorrect. Consider: http://play.golang.org/p/4PCdcVY8Az That begs the question of why the Unmarshalled attribute values in your original example appear to be incorrect. |
I'm aware of that behaviour, hence the name of the issue, foo is being ignored. My example fails because the attributes are being retrieved from the root tag (where there are none), instead of the getBookings tag. Thus when you Marshall the data, foo again is ignored and the attributes end up in the root tag, instead of where I want. |
For Go 1.1, I think all we can do is make foo>bar,attr an error (can't use > and ,attr together). The real fix is too invasive this late in the game. I filed issue #5033 for the error addition. Leaving this bug open for the real fix. Labels changed: added go1.2, removed go1.1. Owner changed to ---. Status changed to Accepted. |
I also think this suggestion would be a great improvement to the XML parser |
I also think this would be an important fix. Currently this is not as straightforward as it should be:
<members>
<member id="1"/>
<member id="2"/>
</members> which is basically going to target the id attribute inside the member elements. Error: "members>member chain not valid with id attr flag" I also tried it this way, although I'd think the first was more logically "correct" Error: "id chain not valid with attr flag" I was hoping in the 2nd attempt, that Go would automagically check for attributes if no child elements matched. I might look into a fix, if noone else is working on this. |
I tried to solve it for two use cases and came up with something: https://gist.github.com/ivankravchenko/036f68e671e33179b636bd58f6ebc9d0 |
More than 4 years later, Golang still can't Unmarshall XML attr properly? |
Everybody, see https://golang.org/wiki/NoMeToo. If you have something unique to add here, please share, but otherwise use the emoji voting reactions at the top of this bug. Fixes welcome. Most Go hackers find ourselves using XML much less than we needed to years ago. |
Refering to the last example, any usage of a namespace must be declared before its use (https://www.w3.org/TR/xml-names/#dt-NSName). Unmarshaling fails as no namespace is explicitly bound. A valid version is like Other issues are duplicates. |
|
what if you have the same attribute under 2 different namespace? |
Then I would make sure the XML is well formed, and namespace the attributes |
@kempjeng 🌮 🌮 🌮 |
by krolaw:
The text was updated successfully, but these errors were encountered: