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

[kdar]

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]

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]

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]

Comment 3:

Status changed to WaitingForReply.

[rsc]

Comment 4:

Labels changed: added release-none.

[kdar]

Comment 5:

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

[LeGEC]

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]

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]

Comment 8:

Labels changed: added repo-main.

[sshikaree]

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).

[mvdan]

@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]

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

[mvdan]

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

[rsc]

Will look at with #13400 in Go 1.7.

[aktungmak]

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]

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

[aktungmak]

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

[iwdgo]

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.

[pgalbavy]

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]

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

[maansaake]

Hit this one today, would be nice to be able to clean up empty elements using tags instead of having to explicitly build the structs and using the struct pointer method. Feels like either changing the omitempty tag's behaviour or adding a new tag for this purpose would be more in line with how the rest of the xml lib works.

[gopherbot]

Change https://go.dev/cl/606475 mentions this issue: encoding/xml: omit parent tags if value is empty