RTF is more structured than HTML.
This highly contentious statement is best made out of earshot of XML
people who, almost unanimously, would disagree in the strongest possible
terms. I happen to believe it is true and that thinking about why it is
true is a useful exercise. It is useful because it forces us to zoom in
on what we mean by the terms "structured" and "unstructured". In my
experience, we do not all mean the same thing by these terms, which
result in confusion and flame wars in equal measure.
If your first reaction on reading the first statement was, "Wow! McGrath
has finally lost it!", then please bear with me for a few more
paragraphs. If you still feel I've lost it by the time we reach the end,
then please come visit me in the Asylum to which I will surely be
dispatched having flown so far over the Cuckoo's Nest.
I remember an episode of the documentary series "The Simpsons" where Dr.
Nick Riviera's  hospital burns down when an errant firecracker
launched by Bart and Milhouse sets a tank on fire marked "inflammable".
Bewildered, Dr Nick exclaims, "Inflammable means flammable?! Boy, what a
country." Sometimes I think the words "structured" and "un-structured",
beloved by the XML community, are much like flammable and inflammable --
more synonymous than antonymous when applied to data formats.
What does the word "structured" mean anyway? What characteristic makes
RTF un-structured? What is it about HTML that makes it un-structured?
Are HTML and RTF un-structured in the same way, or is there a difference
between the two? Why are they both so different from XML? Are they
really different? And just what does XHTML give us by combining HTML and
Lets start with RTF. It can be argued that RTF is, in fact, highly
structured. Its simple stack based control language  can be
unambiguously parsed using a simple pushdown automaton. Oh, and it is
fully compatible with ISO-646. How more structured can you get?
Lets move over to HTML, another famously un-structured format. Compared
to RTF, HTML is definitely un-structured. Unlike RTF, HTML is not
unambiguously parseable. Different HTML parsers can and do produce
different parse trees of the underlying information, but the most common
result of this inherent ambiguity is that browsers produce different
renderings of the same content.
On this basis, I stated that RTF is more structured than HTML. Two RTF
processors are more likely to agree on the fundamental tokenized data
structure they emit than two HTML processors. Does it follow that we
would not have been better off using a stripped down RTF rather than
HTML on the Web?
The answer is a firm "no", but the reason has nothing to do with
structured versus un-structured formats as the terms are commonly used.
Rather, the reason has everything to do with the different conceptual
model each takes towards expressing the document concept.
RTF is a highly structured format that expresses a conceptual document
model in terms of instructions to make marks onto pages of a fixed width
and height. An *imperative* document model that involves providing
detailed instructions to an RTF processor to guide the rendering
HTML is an unstructured format used to express a conceptual document
model as a hierarchy of information chunks. However, the page layout is
not constrained to fixed sizes. Thus, HTML is a *declarative* document
model that describes the hierarchical relationship between bits of
information, but does not specify, in detail, how the information should
HTML's declarative nature makes it a better choice for the Web than RTF,
despite the fact that HTML is less structured than RTF and harder to
parse. Declarative models are much easier to use in a wide variety of
contexts than imperative models, which tend to be tied to one particular
use (e.g., printing onto US Legal sized paper).
Unfortunately, HTML has, over various iterations, developed numerous
features that allow it to be more RTF-like (i.e., more imperative) in
its approach to rendering information. As a consequence, producing HTML
that is, essentially, RTF in drag has become possible. This happens when
HTML is wired to a particular screen size, makes use of nested tables to
achieve fancy layout tricks, or buries textual content in graphics to
make it look nice.
So, what then can we make of XHTML? An XML compatible version of HTML.
XHTML fixes the unstructured side of HTML by making it unambiguously
parseable, but does not address the fundamental issue of declarative
versus imperative information models. Creating XHTML that is wired to a
particular screen size, makes use of nested tables to achieve fancy
layout tricks, and buries textual content in graphics to make it look
nice remains entirely possible.
The difference between structured and unstructured documents has more to
do with imperative versus declarative models. If your HTML is imperative
in its view of the world rather than declarative, then converting it to
XHTML gains you very little.
 "Trilogy of Error"