Find the errors in this XML snippet and say what a parser would report.
A service rejects this response as not well-formed. Identify every problem and say what a parser reports.
<order id=42>
<item>Keyboard</item>
<price>19.99</Price>
<note>Ship to <b>Riga</note></b>
</order>Point out each fault and give the corrected XML.
There are three well-formedness errors. The attribute value in id=42 is unquoted; <price> is closed by </Price>, but XML tag names are case-sensitive; and <b> and <note> overlap instead of nesting. A parser stops at the first fault — the unquoted attribute — and reports a fatal not-well-formed error.
- ✗Thinking XML tag names are matched case-insensitively
- ✗Assuming a parser auto-corrects overlapping or unquoted markup
- ✗Believing well-formedness errors are warnings rather than fatal
- →Why does the parser stop at the first error instead of listing all of them?
- →How would proper nesting of
<b>and<note>look?
Three well-formedness violations in the original snippet:
<order id=42>— the attribute value is not quoted. In XML, attribute values are always quoted:id="42".<price>19.99</price>opens in lowercase but is closed as</Price>. XML tag names are case-sensitive, so those are different tags and the open<price>is left unclosed.<note>Ship to <b>Riga</note></b>— the tags overlap:<b>opens inside<note>, yet<note>closes before<b>. Nesting must be strict:<b>closes before</note>.
An XML parser is a fatal parser: it stops at the first well-formedness error (the unquoted attribute on the first line) and reports a fatal not-well-formed error without parsing further. These are not warnings — the whole document is rejected.
Corrected version:
<order id="42">
<item>Keyboard</item>
<price>19.99</price>
<note>Ship to <b>Riga</b></note>
</order>
