Lists Home |
Date Index |
True, there's always a give and take and judgement calls galore, but the
principle is sound. For example, we do retain an <emph> tag when something
truly requires emphasis (not simply a font change). However if authors key:
<para><emph>Title content:</emph> Para content.</para>
This is a problem, because it will impact output, searching, indexing,
linking, reuse, etc. In most cases, defining content for what it is, not
what it looks like (in a specific output instance) is important. Allowing
minor presentational is fine (e.g., <emph> or even <brk>s in tabular info),
but careful monitoring of correct usage is often required. :-)
From: Bullard, Claude L (Len) [mailto:firstname.lastname@example.org]
Sent: Monday, August 01, 2005 10:45 AM
To: 'Doug Rudder'; 'Michael Kay'; 'Xasima Xirohata'; email@example.com
Subject: RE: [xml-dev] Demand for web services
In a highly formalized (say deep agreement), that is a perfectly valid thing
to do. On the other hand
<emphasis>Bahut bahut dhanyavad!</emphasis> <strong>Bahut bahut
dhanyavad!</strong> <font size="14">Bahut bahut dhanyavad!</font>
is a perfectly valid use of XML.
Redundancy: even with the considerable redundancy, one still relies on local
knowledge in both the content and the markup.
Separating content and presentation is work. XML enables you to do that,
but it also enables you to reinforce meaning by markup, by presentation, and
by context of both. Determine where you want to exchange work for value
because there is sometimes value to be had and sometimes not.
Without the apriori knowledge of the content, this is better:
inEnglish="Thank you very much">Bahut bahut dhanyavad!
with the cost of a lot of metainformation in the markup.
No one wants to type that in every time one says 'thank you'.
Calculate the cost of global expressiveness. Caveat emptor et vendor.
(yes I know it's better to put a URI in the inEnglish value).
From: Doug Rudder [mailto:firstname.lastname@example.org]
Michael Kay wrote:
"It will always be a fragile thing because human readers extract so much
information by "reading between the lines", and specifically from the
presentation. If a paragraph is in a smaller font than the surrounding
paragraphs that says something to me*. But the goal of persuading authors to
make that "something" explicit - to say WHY they want to use a smaller font,
so that the designer can choose an alternative way of conveying the subtle
meaning - is a perfectly valid one, and this goal indeed lies behind a lot
of the adoption of XML."
Exactly! That's why author's and editors are consulted in DTD/Schema design;
their understanding of the content is deeper. Getting them to think beyond
the font size, etc. to the WHY of it is the key. (I can say this without too
much bias because I started here as a tech writer and had to go through the
same learning process myself.)