Why can encoding/xml not fill a map field, and what struct shape do you use instead?

## The rule `encoding/xml` does not handle Go maps. `xml.Marshal` returns an `*xml.UnsupportedTypeError` when asked to encode one, and `xml.Unmarshal` has no matching rule that could fill a map field. There is no tag option that turns one on. This surprises people because reflective codecs for other formats usually do support maps, and because a `<property name="…">value</property>` list obviously *means* a map. ## Why the package declines XML has no canonical encoding of a key/value collection, and every plausible choice loses something: - **Element name as key.** `<colour>red</colour>` is natural, but XML element names are not arbitrary strings — they cannot start with a digit, cannot contain spaces, and are namespace-qualified. A map key like `"total price"` has no legal element name, so the encoding would be lossy in one direction and would fail unpredictably in the other. - **Attribute as key.** `<property name="colour">red</property>` is what real schemas use, but the element name (`property`), the key attribute name (`name`) and the location of the value are all conventions the document chooses. The package cannot know them. - **Duplicates and order.** XML lists are ordered and may repeat a key; a Go map is unordered and cannot hold a duplicate. Any automatic mapping silently discards information. Rather than pick one convention and be wrong most of the time, the package leaves the decision to you — which is consistent with the rest of it: `encoding/xml` never guesses about document shape. ## The shape to use instead Model the wire exactly, then convert: ```go type Property struct { Name string `xml:"name,attr"` Value string `xml:",chardata"` } type Config struct { Properties []Property `xml:"property"` } ``` A slice field collects every occurrence of the repeated element in document order, so nothing is lost. Building the map afterwards is three lines, and — this is the actual benefit — it forces you to decide what a repeated key means: ```go m := make(map[string]string, len(cfg.Properties)) for _, p := range cfg.Properties { if _, dup := m[p.Name]; dup { return fmt.Errorf("duplicate property %q", p.Name) } m[p.Name] = p.Value } ``` Last-write-wins, first-write-wins, or reject: with a map field the codec would have made that choice for you, invisibly. ## When the key is the element name If the vendor's document uses element names as keys — an open-ended set of children whose names you do not know ahead of time — the `,any` option is the tool. A field tagged `,any` receives sub-elements that matched no other field, so a slice of a struct with an `XMLName` field and a `,chardata` field captures both the name and the text of each unknown child. From there the loop is the same. ## What this costs and what it buys The cost is a few lines of conversion per document and a second type: a wire struct that mirrors the XML, and whatever your program actually wants. The benefit is that every lossy decision — duplicate keys, ordering, keys that are not legal element names — is written down in your code where a reviewer can see it, instead of being buried in a codec's default. For a converter reading a third-party feed, that is usually the trade you want anyway, because the vendor will eventually send you something the naive mapping would have quietly mangled.