Encoding empty XML element

[ape...@google.com]

Hello all,

According to the XML standard and empty element, that is an element with empty content and possibly only attributes set, can be both written in the form <br/> and <br></br>. I consider the first one to be more appropriate as it was designed especially for this case and avoid unnecessary tag name repetition.

However, when I use xml.Encoder, I always get the result in the second form. The only documentation issue for empty elements I found was omitempty which is not what I want.

Is there a way to encode empty XML tags in the shorter form? If no, can I suggest this feature to the standard package and how do I do it?

Thanks.

[Jan Mercl]

On Tue, Dec 17, 2013 at 12:05 PM, <ape...@google.com> wrote:
> According to the XML standard and empty element, that is an element with
> empty content and possibly only attributes set, can be both written in the
> form <br/> and <br></br>. I consider the first one to be more appropriate as
> it was designed especially for this case and avoid unnecessary tag name
> repetition.

If both of the forms are allowed by the standard and have equal
semantics - how can one of them can be more or less appropriate?

> However, when I use xml.Encoder, I always get the result in the second form.
> The only documentation issue for empty elements I found was omitempty which
> is not what I want.
> Is there a way to encode empty XML tags in the shorter form? If no, can I
> suggest this feature to the standard package and how do I do it?

The best way is to first convince the dev team that this is a good
idea. Then fill an issue and, optionally but preferably, send a CL for
it.

-j

[ape...@google.com]

Ok, appropriate is not the right word here, let it be preferable. It is a common thing that there are two ways to do something, and we should stick to one of them. Go is not an exception here.

At least I should be able to specify needed behaviour. An additional flag will not hurt.

Thanks, then I will try to reach out to the dev team.

[Volker Dobler]

Am Dienstag, 17. Dezember 2013 15:31:59 UTC+1 schrieb ape...@google.com:

Ok, appropriate is not the right word here, let it be preferable. It is a common thing that there are two ways to do something, and we should stick to one of them. Go is not an exception here.

Not sure why it is preferable. If you are concerned about

the size of the encoded stuff you won't use XML and I do not

see much other advantages beside saving a few bytes. 

At least I should be able to specify needed behaviour. An additional flag will not hurt.

It just has to be implemented, tested, documented and maintained.

And users must understand the flag and use it properly.

I doubt that the benefit outweighs this. 

 

V.

P.S. You may always generate the XML yourself, the convenience

stuff from encoding/xml is basic and general purpose.

[C Banning]

For those who want it here's our hacked pkg/encoding/xml/marshal.go (with example) that support '/>' end tags on empty elements to be consistent with encoding convention for github.com/clbanning/j2x that we use for marshaling JSON strings and map[string]interface{} values.