Exercise 1: Inline Microdata vs. JSON-LD, and Why JSON-LD Became the Default — Possible Solution
====================================================================

WHAT html_lesson_09_2's OWN INLINE MICRODATA APPROACH LOOKED LIKE
------------------------------
Per this chapter, html_lesson_09_2 taught microdata using
`itemscope`/`itemprop` attributes "woven directly into visible HTML."
This means the structured-data markers are attributes added onto the
same tags already rendering the page's own visible content — an
`itemprop="headline"` attribute might sit directly on the `<h1>` tag a
reader actually sees, for example.

WHAT THIS CHAPTER'S OWN JSON-LD APPROACH DOES INSTEAD
------------------------------
Per this chapter's own code example, JSON-LD packages the identical
schema.org information — headline, author, date published — as a
self-contained `<script type="application/ld+json">` block, entirely
separate from the visible HTML. The same @type/@context vocabulary
describes the same real-world concepts; only the delivery mechanism
differs.

WHY THESE ACCOMPLISH THE IDENTICAL JOB
------------------------------
Per this chapter, "JSON-LD does the identical job... as one
self-contained script block, entirely separate from the visible
markup." Both approaches ultimately communicate the same structured
facts about the page to a machine reader; a search engine parsing
either one arrives at the same understanding of what the page
represents.

WHY JSON-LD BECAME THE RECOMMENDED DEFAULT
------------------------------
Per this chapter, JSON-LD is now recommended "specifically because it
doesn't require touching the page's own display HTML at all." Inline
microdata requires adding attributes directly onto the same elements
used for visible rendering, which means any change to the structured
data requires editing markup that's also responsible for how the page
actually looks — a real coupling risk, since a mistake made while
editing structured-data attributes could just as easily break visible
rendering. JSON-LD's own separation removes that risk entirely: the
structured-data block can be added, edited, or removed without ever
touching the elements a visitor actually sees.

WHY THIS SEPARATION IS A GENUINE PRACTICAL ADVANTAGE
------------------------------
Beyond just being cleaner, keeping structured data separate from
display markup means the two concerns can be maintained independently
— a content editor changing visible text doesn't risk breaking
structured data, and a developer updating structured data doesn't risk
breaking the page's own appearance. This is exactly the kind of
separation-of-concerns benefit that makes JSON-LD easier to maintain at
scale than inline microdata.

WHY THIS WORKS AS AN ANSWER
------------------------------
It describes precisely what each approach requires structurally (
attributes on visible elements vs. a separate script block), confirms
both communicate identical information, and explains the specific
maintenance/coupling risk JSON-LD avoids that inline microdata
carries, which this chapter names as the real reason for its
recommended-default status.