How does Go's encoding/xml decide which struct field an XML element or attribute fills?

## The question encoding/xml asks `xml.Unmarshal(data []byte, v any) error` walks the document and, for every element and attribute it meets, asks the destination struct type a single question: *which of your fields wants this?* The answer comes entirely from the struct's shape and its field tags, read by reflection. Nothing else — no registration, no schema, no generated code — takes part. ## Rule 1: exported fields only A field whose name starts with a lower-case letter cannot be set through reflection, so `encoding/xml` skips it. It is not an error; the field simply keeps its zero value. This is the single most common surprise for someone porting a hand-rolled parser, where the parser could of course assign to any field it liked. ```go type Item struct { Title string `xml:"title"` // filled price string `xml:"price"` // never filled: unexported } ``` ## Rule 2: the name comes from the tag, then the field name Each field's XML name is the leading part of its `xml:"..."` struct tag. With no tag, the Go field name is used as-is. So `Title string` matches `<Title>`, while ``Title string `xml:"title"` `` matches `<title>`. Because XML documents are usually written in a naming style that does not match Go's exported-identifier style, most real wire structs tag every field. A struct tag is an ordinary string literal held in the type's metadata — inert as far as the compiler is concerned. It only means something because `encoding/xml` chooses to read it. ## Rule 3: attributes are a different namespace from elements XML has two places a value can live: a child element and an attribute of the current element. `encoding/xml` keeps them strictly apart. A field is matched against attributes only if its tag has the `,attr` option: ```go type Item struct { ID string `xml:"id,attr"` // <item id="7"> Title string `xml:"title"` // <title>...</title> } ``` Getting this backwards produces an empty field and no error. JSON has no attribute concept at all, so the distinction is one of the first things to internalise when moving to XML. ## Rule 4: XMLName If the struct has a field named `XMLName` of type `xml.Name`, `Unmarshal` records into it the name of the element the struct was decoded from. If that field also has a tag, the tag becomes a constraint: the element must have that name or `Unmarshal` returns an error. That makes `XMLName` a cheap tripwire — the one place where the package will actually complain that you pointed it at the wrong document, rather than handing you an empty struct. ```go type Feed struct { XMLName xml.Name `xml:"rss"` // decoding <feed> here is an error } ``` On the encoding side, `xml.Marshal` uses the same field to choose the element name it writes. ## Rule 5: shapes - A **struct** field means "descend into this element". - A **slice** field accumulates every occurrence of a repeated element. A non-slice field decoded from three matching elements ends up holding the last one. - A **pointer** field is allocated when a matching element appears, so it distinguishes an absent element from an empty one. - An **embedded (anonymous) struct** has its fields treated as if they were declared in the outer struct. ## Rule 6: no match is not an error Elements and attributes that match no field are skipped in silence, and fields that no input matched keep their zero values. `encoding/xml` returns an error for malformed XML, for a type it cannot fill, and for an `XMLName` tag mismatch — but never for "the document said something you did not ask about" or "you asked for something the document did not say". The practical consequence: a decode that returns `nil` proves the bytes were well-formed XML, not that you got the data you wanted. When a field comes back empty, the bug is in the matching rules above, not in the document.