In an encoding/xml struct tag, what do the ,attr and ,chardata options and an a>b name mean?

## The shape of the tag An `encoding/xml` field tag is a string of the form `xml:"name,option,option"`. The part before the first comma is the XML name to match; everything after it is options. Either half may be empty: `xml:"id,attr"` gives both, `xml:"title"` gives a name only, and `xml:",chardata"` gives an option only, leaving the name unused. ## ,attr — the value lives on the element, not under it XML can carry a value in two places, and they are not interchangeable: ```xml <item id="7"><title>Bolt</title></item> ``` `id` is an **attribute** of `<item>`; `title` is a **child element**. A field is matched against attributes only when its tag says `,attr`. This is the difference that most often produces an empty field for someone coming from a format with no attributes: `ID string \u0060xml:"id"\u0060` looks right and matches nothing. On output, `xml.Marshal` writes an `,attr` field into the start tag rather than as a nested element, so the same struct round-trips. ## ,chardata — the element's own text An element that has attributes *and* text needs somewhere to put the text, because the text is not a named child: ```xml <price currency="EUR">9.99</price> ``` Map it with a small struct: one field tagged `currency,attr` and one tagged `,chardata`. The `,chardata` field accumulates the character data inside the element. It works on a `string` or `[]byte` field. A caution worth knowing: if a struct has both a `,chardata` field and child-element fields, the character data field also collects the whitespace *between* those child elements, because that whitespace is character data too. Use `,chardata` on leaf-ish elements — ones whose content is text — and not on a container. ## a>b — descending without a struct per level Documents produced by enterprise tooling nest deeply, and declaring a Go struct for every wrapper level is tedious. A tag name containing `>` walks the path for you: ```go type Item struct { Title string `xml:"metadata>title"` Author string `xml:"metadata>author"` } ``` That binds `<item><metadata><title>…</title><author>…</author></metadata></item>` to two flat fields. A tag beginning with `>` is shorthand for the field's own name followed by `>`. On the encoding side the rule is mirrored: fields that name the same parent path and appear next to each other are enclosed in one shared parent element, so marshalling the struct above emits a single `<metadata>` containing both children. The path form binds the innermost name; it does not let you skip an arbitrary number of levels or use wildcards. Every step must be spelled out. ## ,innerxml — keep the bytes ```go type Entry struct { Summary string `xml:"summary"` Raw []byte `xml:",innerxml"` } ``` A `,innerxml` field receives the raw, unprocessed XML nested inside the element, verbatim. The other fields are still populated normally — `,innerxml` is additive, not exclusive. It is the escape hatch for a subtree whose shape you do not want to model: pass it through untouched, store it, or decode it later with a second struct. It is also the fastest way to see what a vendor document actually contains at a given level. ## ,any and the rest `,any` marks a field as the catch-all for sub-elements that matched no other field, which is useful for a heterogeneous list. `,comment` collects XML comments. `,cdata` (on output) writes the field's text inside a CDATA section. `,omitempty` affects marshalling only: it suppresses an empty field from the output, and it applies to attributes as well as elements. ## Why the grammar looks like this Every one of these options exists because XML's data model is richer than a struct's: an element has a name, ordered children, unordered attributes, text, comments and namespaces, while a Go struct has only named fields. The tag is the small language that projects one onto the other, and each option names one XML construct that would otherwise have no Go home. Learning the five that matter — `,attr`, `,chardata`, the `a>b` path, `,innerxml`, `,any` — covers nearly every real document.