Skip to content
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: omit parent tags if value is empty #2 #7233

Open
kdar opened this issue Jan 29, 2014 · 19 comments
Open

encoding/xml: omit parent tags if value is empty #2 #7233

kdar opened this issue Jan 29, 2014 · 19 comments
Labels
early-in-cycle A change that should be done early in the 3 month dev cycle. NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@kdar
Copy link

kdar commented Jan 29, 2014

What steps will reproduce the problem?
http://play.golang.org/p/m2rU4cPOBo

What is the expected output?
<OmitEmpty></OmitEmpty>

What do you see instead?
<OmitEmpty><Vars></Vars></OmitEmpty>

Please provide any additional information below.
https://golang.org/cl/6569067/

This was originally: https://golang.org/issue/4168
Ran into this issue today making a restful API service. Ended up having to make my own
custom Marshaller.
@LeGEC
Copy link

LeGEC commented Feb 12, 2014

Comment 1:

Further comments on this issue:
In this case, the "omitempty" directive has actually no effect :
http://play.golang.org/p/HG7io7mH7l
IMHO, the extra ",omitempty" should be taken as a clear directive in this case (1-step
deep node list).
For a deeper nested list, the "expected behavior" is ambiguous :
type Ambiguous struct {
    Bees []string `xml:"Beez>Bees>Bee,omitempty"` //I don't have a "natural" argument for this one ...
}
My choice would be : ommit the base "Beez" node in the output.
One point for this choice :
- if we ommit the base node, there still is a way to write a type structure which will
use only xml annotations and which will contain "<Beez></Beez>" in the
Marshal-ed output :
type Disambiguated struct {
    Beez Nested `xml:"Beez"`
}
type Nested struct {
    Bees []string `xml:"Bees>Bee,omitempty"`
}
- if we don't ommit the base node, I don't see how to achieve this without writing a
custom Marshaller.
Regarding the "break backward compatibility" part :
 * it shouldn't break the Unmarshaling of a previously Marshal-ed structure,
 * it could indeed change the output of a program, but as I stated, I think this output is the one expected by the programmer if ",omitempty" is specified.
This is an adapted repost of this comment :
https://golang.org/issue/4168?c=10

@rsc
Copy link
Contributor

rsc commented Mar 3, 2014

Comment 2:

Are you asking for an omitparent tag? Because we're still not going to change the
behavior of omitempty at this point.

@rsc
Copy link
Contributor

rsc commented Mar 4, 2014

Comment 3:

Status changed to WaitingForReply.

@rsc
Copy link
Contributor

rsc commented Mar 4, 2014

Comment 4:

Labels changed: added release-none.

@kdar
Copy link
Author

kdar commented Mar 4, 2014

Comment 5:

Well, I guess that would be the only option given the Go1 compat guarantee.

@LeGEC
Copy link

LeGEC commented Mar 4, 2014

Comment 6:

@rsc : I'd rather have the modified behavior in 1.3.1 or 1.4 than add an extra directive
just for this corner case.

@gopherbot
Copy link

Comment 7 by TheDonDaniello:

I have the same problem: no way to get rid of the parent tag even if it's marked with
omitempty and does not have any children or attributes.

@griesemer
Copy link
Contributor

Comment 8:

Labels changed: added repo-main.

@sshikaree
Copy link

You can use a pointer to a structure. While it's uninitialized, pointer is nil and omited by marshaller.
http://play.golang.org/p/tdiGkAdQAQ
But I think it would be more convenient if we could also omit the structure ("Time" in example).

@rsc rsc added this to the Unplanned milestone Apr 10, 2015
mvdan added a commit to mvdan/gexf that referenced this issue Sep 17, 2015
See golang/go#7233. Prefer correct Go over slightly
lighter XML.
@mvdan
Copy link
Member

mvdan commented Sep 17, 2015

@rsc improving xml namespaces support (#9519) is targeted at 1.6. It modifies the output of xml marshaling in a similar way to what is proposed here.

Could this issue be considered for 1.6 too?

On a previous issue you said this wasn't important enough to break compatibility for, yet the namespace issue is technically breaking compatibility as well. Although both changes should still make the marshaling output valid xml.

@ianlancetaylor ianlancetaylor modified the milestones: Go1.6, Unplanned Sep 17, 2015
@ianlancetaylor
Copy link
Contributor

I changed the milestone to Go1.6, but somebody still has to actually do the work.

@mvdan
Copy link
Member

mvdan commented Sep 17, 2015

@kdar's patch in https://golang.org/cl/6569067/ can probably still be applied.

@rsc rsc changed the title encoding/xml: Omit parent tags if value is empty #2 encoding/xml: omit parent tags if value is empty #2 Nov 5, 2015
@rsc
Copy link
Contributor

rsc commented Nov 25, 2015

Will look at with #13400 in Go 1.7.

@rsc rsc modified the milestones: Go1.7, Go1.6 Nov 25, 2015
@rsc rsc modified the milestones: Go1.8, Go1.7 May 18, 2016
@quentinmit quentinmit added the NeedsFix The path to resolution is known, but the work has not been done. label Oct 7, 2016
@rsc rsc modified the milestones: Go1.9Early, Go1.8 Oct 26, 2016
@bradfitz bradfitz modified the milestones: Go1.10Early, Go1.9Early May 3, 2017
@bradfitz bradfitz added early-in-cycle A change that should be done early in the 3 month dev cycle. and removed early-in-cycle A change that should be done early in the 3 month dev cycle. labels Jun 14, 2017
@bradfitz bradfitz modified the milestones: Go1.10Early, Go1.10 Jun 14, 2017
@rsc rsc modified the milestones: Go1.10, Go1.11 Nov 22, 2017
@aktungmak
Copy link

Is this likely to get merged anytime soon? It seems that all the work is done.

It is a real deal breaker when handling NETCONF XML since most vendors do not accept empty tags. Having this work properly will really unleash the declarative nature of struct tags.

@SamWhited
Copy link
Member

The Go 1.10 tree is already closed and this has been moved to Go 1.11 which will open sometime in February.

@aktungmak
Copy link

OK, here's hoping it gets included and this trivial issue can be put to bed.

@iwdgo
Copy link
Contributor

iwdgo commented Mar 28, 2018

While reading all encoding/xml issues together, documentation of encoding/xml states exceptions to rules based on tags applying to field including "omitempty" and hyphen ("-") which is independent of value. The following paragraph of the documentation states that a field is nested in its parent tags. This proposal implies that the parents are omitted when the documented tag applies to the field.

@bradfitz bradfitz modified the milestones: Go1.11, Go1.12 May 18, 2018
@gopherbot gopherbot modified the milestones: Go1.12, Unplanned May 23, 2018
jstemmer added a commit to jstemmer/go-junit-report that referenced this issue Mar 22, 2022
Go doesn't omit empty parent tags for empty values[1], so we'll work
around this for now by creating a pointer to the property slice.

[1]: golang/go#7233.
@pgalbavy
Copy link

I hit this one today and because of the relative flat nature of the actual data I want to marshal the creation of dummy structs is more than painful - when I want to set the tag I have to initialise N layers of containing structs, which when anonymous is convoluted and prone to errors. While the destination XML has lots of tag options my use-case is one deep tag or none at all.

If there is hesitation around changing the behaviour of ",omitempty" then perhaps an ",omitallempty" tag could be used to be explicit about the desired behaviour?

@amostech
Copy link

Has this ever gotten any traction? It looks like it still isn't going to be added. :/

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
early-in-cycle A change that should be done early in the 3 month dev cycle. NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests