Re: XML & Technical Writers...(not too long!)

[Mark Baker <mbaker -at- OMNIMARK -dot- COM>]

Deborah Ray wrote:


>Your point about creating standard markup languages based on XML
>has some validity,

I'm not sure what you thought my point was. The person I was replying to
suggested that there would be a DTD for documentation. I pointed out that
there already were some and that they were by-and-large failures.

>Attempting to standardize a TDML would lead quickly to
>problems like those with HTML--that is, TDML wouldn't fit
>all needs any more than HTML does, and the result would be
>similar to what Microsoft and Netscape have done adding
>extensions to HTML.

Which is exactly the point I was trying to make.

>That's not the point of XML. The point is that XML offers the
>potential to get away from this problem.

No it doesn't. Lets solve the display language problem by having everybody
write their own display code -- I don't think so. If people cannot write
good HTML, why should we think they will be able to write good
XML/XSL/CSS/HTML? The correct solution would be to create a robust and well
though out formatting language and let people convert to it on they fly when
they needed to display. (Actually, HTML 4.0/CSS will probably be close
enough for most proposes.) The point people miss about XML is that XML is
highly convertable. Information should be stored in a neutral format and
converted to media specific formats as required for display.

Shipping XML plus XSL to the browser so that the browser can run the XSL
program to turn the XML into HTML/CSS is a terrible waste of band-width.
Convert it on the server side and deliver the displayable version to the
browser.

The idea that the authoring format, the searchable format, and the
displayable format should all be one and the same is not the promise of XML,
it is a complete misunderstanding of the potential of markup languages.

>>A DTD tells you what tags there are and what order they are allowed to be
>>in. Nothing else.
>
>Nope, not exactly. From the tools standpoint, maybe. But not from
>the information providers' standpoint. Take, for example,
>the following code, which you could easily create using
>XML (technically speaking, using an XML-derived markup language):
>
>(Let's take the DTD for this one as a given--quibbling
>over DTD syntax misses the bigger issue completely.)
>
><CITATION SRC="Technical Communication" VOLUME="Nov96"
>AUTHOR="David Leonard">Though not a cure-all for society's
>ills, the Web is an important medium that is changing the
>way we work and learn."</CITATION>
>
>For technical writers, being able to identify this information
>has worlds of potential!!

Absolutely, but how is that potential to be realized? I trust you are not
suggesting that XML is actually a format to be delivered to users to be read
directly? If not, then you will need to process those author-meaningful tags
into a viable presentation form. You may have implied meaning in the names
you give to tags, but that meaning is made explicit in an application that
actually treats the tagged elements accordingly.

(Note that I was responding to the assertion that the *DTD* gives meaning to
tags in a markup language. That the tags have meaningful names is no thanks
to the DTD. There is nothing in the syntax of a DTD that expresses the
meaning of tags.)

>You're perhaps right that "custom processing applications" do
>exciting work--technology is amazing these days, isn't it? But,
>I suspect tech writers are even more excited about a markup
>language that can make developing, designing, reusing, re-purposing,
>and effectively presenting information easy and affordable.
>That's what XML will do for us.

No, that's what applications that process XML will do for us. XML is just
angle brackets in a stream of ASCII text. There is no magic to it. Its
importance lies in the fact that, because it is a simple standard for
interpreting angle brackets in ASCII text streams, it is easier to develop
applications that process it. You cannot reuse, re-purpose, or present
information without processing applications, and you will have a struggle to
develop or design without them as well.

---
Mark Baker
Manager, Corporate Communications
OmniMark Technologies Corporation
1400 Blair Place
Gloucester, Ontario
Canada, K1J 9B8
Phone: 613-745-4242
Fax: 613-745-5560
Email mbaker -at- omnimark -dot- com
Web: http://www.omnimark.com