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 #4168

Closed
gopherbot opened this issue Sep 27, 2012 · 12 comments
Closed

encoding/xml: Omit parent tags if value is empty #4168

gopherbot opened this issue Sep 27, 2012 · 12 comments

Comments

@gopherbot
Copy link

by vladimir.webdev:

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/
@rsc
Copy link
Contributor

rsc commented Oct 6, 2012

Comment 1:

Labels changed: added priority-later, go1.1maybe, removed priority-triage.

Status changed to Accepted.

@rsc
Copy link
Contributor

rsc commented Mar 12, 2013

Comment 2:

I think this is working as intended. Or at least working as implemented and not possible
to change now.
In Vars>Var,omitempty, the omitempty here is being applied to the Var, not the whole
Vars>Var. So it does omit individual empty strings from the slice:
http://play.golang.org/p/ZrcLRf86Vd.
At this point, I see this as something someone might have intended, and I'm reluctant to
break their code to switch to this alternate meaning. So I think we have to live with
this for now. It is possible to work around by using an extra element in the data
structure (a pointer to a struct containing a []string, for example, or just a
*[]string).

Status changed to Unfortunate.

@lukescott
Copy link

Comment 3:

Why hasn't this been fixed? Every single XML API is picky about extraneous tags. There
is a code review here:
https://golang.org/cl/6569067/
So we have a patch, but it hasn't been included?
(Currently using tip)

@rsc
Copy link
Contributor

rsc commented Sep 13, 2013

Comment 4:

My comment #2 explains why this is not being done.
If you need to omit the outer tag, do not use > in your tag names.

@lukescott
Copy link

Comment 5:

It seems backwards to me. If you have multiple fields referring to the same artificial
parent tree, they do get included. I'm not sure why having an empty parent is useful at
all. In my case it causes the API I'm working with to throw a fatal error. Doing the
workaround really defeats the purpose of "omitempty" + ">".
Just to make everyone happy, could we have tags like:
omitempty
omitempty-parent
omitempty+parent
Where "+parent" would mean omit this AND the parents. "-parent" would mean don't omit
the parents. "omitempty" would use -parent by default, for now.

@lukescott
Copy link

Comment 6:

It seems backwards to me. If you have multiple fields referring to the same artificial
parent tree, they do get included. I'm not sure why having an empty parent is useful at
all. In my case it causes the API I'm working with to throw a fatal error. Doing the
workaround really defeats the purpose of "omitempty" + ">".
Just to make everyone happy, could we have tags like:
omitempty
omitempty-parent
omitempty+parent
Where "+parent" would mean omit this AND the parents. "-parent" would mean don't omit
the parents. "omitempty" would use -parent by default, for now.
(Or multiple tags - Not sure how these work. "omitparent" perhaps)

@rsc
Copy link
Contributor

rsc commented Sep 13, 2013

Comment 7:

If we were designing from scratch then I would probably be inclined to make it work the
way you expect.
We are not designing from scratch. Compatibility with older versions of Go (up to Go 1)
is important, and this is not important enough to break compatibility for.

@lukescott
Copy link

Comment 8:

But we can't add a tag, like "omitparent", that can't be removed later?

@rsc
Copy link
Contributor

rsc commented Sep 14, 2013

Comment 9:

We could possibly do omitparent but we're in a feature freeze. File a new
bug after Go 1.2 has been released. Thanks.

@LeGEC
Copy link

LeGEC commented Feb 11, 2014

Comment 10:

Go 1.2 is out, refreshing this request.
I would like to point out that, in this case, the "omitempty" directive has actually no
effect :
http://play.golang.org/p/g7WhtJWEnc
IMHO, the extra ",omitempty" should be taken as a clear directive in this case (1-step
deep node list).
Granted, I don't see a natural behavior for a deeper nested node list :
type Ambiguous struct {
    Bees []string `xml:"Beez>Bees>Bee,omitempty"` //ok, I don't know which node should be omitted
}
Regarding the "break backward compatibility" part :
If I'm correct : it wouldn't break the Unmarshaling of a 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 he specifies ",omitempty".
Thanks.

@ianlancetaylor
Copy link
Contributor

Comment 11:

Russ's comments have consistently said that we aren't going to change this behaviour. 
This issue is closed.  If you really want to reopen it, please discuss that on the
golang-dev@googlegroups.com mailing list, not here in the issue tracker.
Russ suggested opening a brand new issue for an omitparent tag.  Please do that if you
would find it useful.

@gopherbot
Copy link
Author

Comment 12 by work.jlsun:

if we have other ways to omit parent tag??????

@rsc rsc added this to the Go1.1 milestone Apr 14, 2015
@rsc rsc removed the go1.1maybe label Apr 14, 2015
@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

5 participants