Theory
The sponsors break the file
The fest committee sends sponsor data, and a teammate appends it to events.xml like this:
<events> ... </events>
<sponsors> ... </sponsors>
Two tidy lists, both perfectly well-formed inside. The parser rejects the whole file anyway.
His second attempt renames a tag to <Event> for style, closing it with </event>. Rejected again.
Two rules, both structural, both unforgiving: one root, and case matters.
Theory
One envelope per parcel
A courier accepts a parcel with exactly one outer envelope. Put 2 sealed envelopes on the counter with no wrapper around them and ask to send "it": the clerk asks, which one IS the parcel?
The root element is that single outer envelope: every scrap of data travels inside it. Two top-level elements = 2 envelopes and no parcel: the parser, like the clerk, refuses the ambiguity.
Theory
The root element rule
Every XML document has exactly one root element (also called the document element) that contains all other elements.
<events>wrapping every<event>satisfies it<events>...</events><sponsors>...</sponsors>at top level violates it: 2 roots- the declaration does not count: it is an instruction, not an element, so it legally sits above the root
The fix for the sponsor data: one wider envelope. A new root <festdata> containing BOTH <events> and <sponsors> restores the single-root shape.
Practical
Two roots (rejected) vs one root (accepted)
<!-- REJECTED: two top-level elements -->
<?xml version="1.0"?>
<events>
<event><name>Garba Night</name></event>
</events>
<sponsors>
<sponsor>Surat Textiles</sponsor>
</sponsors>
<!-- ACCEPTED: one root wraps everything -->
<?xml version="1.0"?>
<festdata>
<events>
<event><name>Garba Night</name></event>
</events>
<sponsors>
<sponsor>Surat Textiles</sponsor>
</sponsors>
</festdata>
Theory
Case sensitivity, everywhere
XML names are case-sensitive, with no exceptions:
<event>,<Event>and<EVENT>are 3 different elements- a start tag must be closed by an end tag of identical case:
<Name>...</name>is a mismatch error - attribute names follow the same law: id and ID are different attributes
HTML let you write <BODY> and close with </body> for 20 years; that reflex is the bug generator here. The professional defence is a naming convention: pick all-lowercase (or camelCase) for a project and never deviate.
Quiz
A document contains <events>...</events> followed by <sponsors>...</sponsors>, both at top level, both internally perfect. What does an XML parser do?
- Reads both: XML allows multiple top-level sections
- Rejects the document: it has 2 root elements instead of exactly 1
- Reads <events> and silently ignores <sponsors>
- Merges them into one implicit root automatically
Show the answer
Rejects the document: it has 2 root elements instead of exactly 1
One root is absolute: the parser refuses the whole file, however clean each section is: this is precisely the teammate's bug from the hook. Option C describes a mercy parsers do not extend; XML rejection is all-or-nothing, never partial. Option D is what HTML's forgiving engines might improvise, and unlearning that expectation is half of learning XML. The repair is always the same envelope trick: invent one wider root (<festdata>) and move both sections inside.
Think first
Why so strict? Argue the design
HTML browsers guess through errors and the web survives. Before tapping: why do XML parsers refuse instead of guessing? Think about WHO reads each format.
Show the answer
HTML's reader is a human via a browser: a wrong guess costs a slightly crooked page, and the human copes. XML's reader is usually another program: FestConnect's app parsing events.xml, a bank parsing a payment file. A guessing parser might silently read the WRONG data (which envelope? which <event>?), and machines do not notice crooked. Refusing loudly at the first violation means errors surface in development, not as corrupted data in production. Exam phrasing: strict well-formedness makes XML reliable for machine-to-machine data exchange.
Watch out
The 2 habits that trip HTML veterans
Decorative capitalisation: typing <Event> in one file and <event> in another because both "look fine". Pick lowercase, always, everywhere: convention beats memory.
Appending at top level: new data pasted after the closing root tag (the sponsor bug). New sections go INSIDE the root, or the root gets renamed wider. And remember the one legal thing above the root: the declaration, which is not an element.
Theory
Two rules, one mental model
Both rules serve the same master: a parser must be able to walk the document as ONE tree with no ambiguity: one trunk (the root), branches that match exactly (case-identical tags). Hold the tree image; it returns when jQuery walks HTML's tree in Unit 2 and when readyState hands you responseXML in Unit 4. Next lesson names the document's 2 sections formally: the prolog and the document element section.
Summary
Key takeaways
- Exactly ONE root element (the document element) wraps every other element.
- Two top-level elements = ill-formed; wrap them in a new wider root instead.
- The XML declaration sits above the root legally: it is an instruction, not an element.
- Case-sensitive everywhere: <Event> is not <event>; start and end tags must match exactly.
- Pick a case convention (all lowercase) and never deviate.
- Parsers refuse rather than guess: strictness is what makes machine exchange safe.
- Memory hook: one envelope, matching labels.