This is the mail archive of the davenport@berkshire.net mailing list for the Davenport project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Antwort: Re: DAVENPORT: Three more Questions.


/ Konrad Hinsen <hinsen@cnrs-orleans.fr> was heard to say:
| > <para>This is just some [[make these words fat cursive]] random blather</para>
| > The answer is, you can't. That's not what structural markup is all about.
| > Rather, you should author descriptively, not presentationally:
| 
| That reminds me of a question that I have always wanted to ask some
| more knowledgeable people in this subject: what's fundamentally wrong
| with having both structural and graphical markup? Sure, people could

There's nothing wrong with it in any absolute sense, it just
isn't what DocBook does. And it does have some significant
problems and limitations.

| be tempted to use graphical markup instead of properly learning
| structural markup, but that's a problem of education (and perhaps
| punishment ;-)

It's much worse than a problem of education. Graphical markup is
largely useless for automated processing of documents. Because
it doesn't have any semantic meaning, it isn't easy to transform
it into something more useful. Two of the big benefits of
structured markup are:

- separation of content and presentation, so that you can make
decisions about presentation _after_ the markup is finished. For
example, you can render on different output devices, you can
make documents accessible to the blind with audio, etc.

- semantic tagging so that you can access documents with other
automated processes in a meaningful way (finding all trademarks
or host names, finding all occurances of the word "print" in
chapter or section titles, etc.)

Presentational markup is likely to be meaningful only on a
specific kind of display device, perhaps only at a specific
resolution.  It's just not practical to maintain large document
collections marked up this way, the technology changes too fast.

If the life expectancy of your documents is short and their
potential for reuse is limited, then graphical markup is
fine. So is RTF.  Graphical markup is about the same thing as
RTF for most applications.

| I can think of a few applications where graphical markup seems the
| only solution. Suppose, for example, that you want to write a manual
| for a standard word processor, and you want to demonstrate what kind
| of text the menu item "italic" produces.

This is a bad example for a couple of reasons. First, the menu
item "italic" doesn't do one thing (probably), it does many
things. It selects the italic posture of the current font.  You
can't represent that with graphical markup any more easily than
I can with structural markup:

<para>The <guimenuitem>italic</guimenuitem> menu selects the
italic posture of the current font. For example, see <xref
linkend="screenshot"/>.</para>

| Moreover, having the "escape mechanism" of explicit graphical markup
| would lower the intimidation threshold that keeps people from starting
| with structural markup. Anyone considering DocBook, for example, runs
| the risk of not being able to produce an essential effect he wants
| without a one-year course in DSSSL. It might then seem a better choice
| to stay away from DocBook completely.

I know. It's a pity. Maybe XSL will be more approachable. On the
other hand, most people dramatically overestimate the extent to
which any particular effect is "essential".

I have a theory about authors: they have no business even
thinking about the presentation of thier documents, let alone
tinkering with it. That's not their job. Authors are supposed to
write clear, crisp prose. They're supposed to accurately
describe the semantics of the things they're writing
about. Presentation is someone else's job.

| LaTeX is an example of a system that permits both structural and
| graphical markup, and in my experience it has worked very well. I use
| graphical markup very sparingly, and yet I am always glad that I have
| it.

You've never tried to drag LaTeX documents uphill into meaningful
structured documents, I can tell. Sometimes {\it word} means that
"word" is a filename, sometimes {\it word} means that "word" is a
command, sometimes {\it word} means that "word" is an optional
parameter, sometimes {\it word} just means _WORD_.

It's a nightmare. 

Case in point: my own book on TeX was written in LaTeX. It's now
out of print, so I want to make it available on my website. In
order to do that, I insist on first turning it into DocBook so
that I can format it nicely for the web.

Now, I really tried hard, being a structure geek, to make sure
that I did things 'right'. I defined new macros for
\filename{}s, \command{}s, etc. And it's still a huge chore to
drag it uphill.  There are just too many places where I inserted
little bits of graphical markup, places where I got lazy or
forgot to use the right macro.

In short, for source documents, "semantic markup good",
"presentational markup bad". ;-)

                                        Cheers,
                                          norm

-- 
Norman Walsh <ndw@nwalsh.com>      | If you cannot find the truth right
http://www.oasis-open.org/docbook/ | where you are, where else do you
Member, DocBook Editorial Board    | expect to find it?--Dogen


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]