Re: XML & Technical Writers...(long)

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

Eric J. Ray wrote:

>Perhaps we're saying the same thing from different sides

Perhaps, at least in some cases. Frankly I am not always certain from your
post when you are agreeing with me and when you are disagreeing!

>But this completely misses the point--and the functionality--of XML.
>None of us would advocate creating a TDML, because by the very
>nature of our profession, our needs tend to be unique to what
>we're doing and unique to our audience.

That was my point -- that creating an industry wide DTD misses the point of
XML. Nevertheless, it is a very widely held view and one that needs to be
actively questioned. Yes, unique needs require unique solutions and that's
where XML shines -- when you create useful processing applications to
process your new tagging language.

>The fact is, XML lends itself to development of new tagging languages
>to meet specific needs, and the few tools currently available support
>this flexibility. Currently available (crude, but functional) XML
>editing tools allow users to specify the DTD they want to use,
>and that DTD could be either a common standard OR a DTD that meets
>specific unique needs. Additionally, the announcement of full XML
>support in Netscape Communicator 5 as well as the next version
>of Internet Explorer, lends some additional credibility to the
>XML-as-a-generic-solution model, rather than to your XML-as-another-
>expensive-SGML-product version.

I don't think I suggested that, but lets ask what "full XML support" means.
Presumably it means an XML parser built into the browser. That's great, but
all a parser does is identify the elements contained in a document. Once the
elements are identified, some processing application has to do something
with those elements (such as display them). The processing application can
be any program written in any programming language. You could argue that all
Java enabled browsers have full XML support now since you could write an XML
parser and an XML processing application in Java and ship them with your XML
document. But the point is, no browser can have built in support for
arbitrary tag sets the way they support the specific tag set of HTML. If you
create a tag and want the tagged data displayed, you have to write a program
to tell the browser how to display it. At the simplest level, this isn't
hard, but it has to be done.

>Mark, perhaps this is the time to point out that (by my understanding)
>your company provides tools to do many of these things, and to do so based
>on any arbitrary DTD.
>See http://www.omnimark.com/magazine/tips/htmldown.html for
>a neat example of converting arbitrary XML to HTML code. This tool,
>among others, makes it feasible *right now* to store data as XML
>and to provide it to users as HTML.

This is correct. I seem to have given you the impression that I don't think
people should adopt XML right now. Nothing could be further from the truth.
I'm not saying wait for the applications. The applications are here.
OmniMark will let you do all the XML processing you could wish for, and it's
a powerful, robust, mature and easy-to-use language. What I'm saying is, XML
isn't magic. If you create a new language, you have to create processing
applications that understand it.

>Why store data as XML--as opposed
>to just storing it as HTML? Because keeping information in some
>XML flavor allows you to preserve meta-information about the data,
>as shown below.

Exactly. But note that you won't be able to act on that meta-information
until you write an application to process it. I'm not saying you have to
write all your applications up front. On the contrary, you should make your
XML tagging as rich and as generic as possible so that you can make use of
it in future projects you haven't thought of yet -- by writing new
processing applications.

>>Okay, here's an XML DTD:
>>A DTD tells you what tags there are and what order they are allowed to be
>>in. Nothing else.
>
>Actually, it tells you what tags there are, what must/may/can/may not
>be there, and that's enough.
You are correct, though I'm not sure I see the difference.
>Let's try another DTD example:
>...
>Identifying an element as a
>question as shown here, rather than as bold and italic as it
>might be presented in an HTML document, makes it possible
>(given scripting or presentation tools) to manipulate, present,
>abstract, or reformat the document based on the content.

Yes, given scripting or presentation tools -- in other words, processing
applications. The point is, just because human beings associate meanings
with the words used to name tags does not give them meaning to processing
applications. People have to write processing applications to make tags
actually behave in the way they intend.

>At a broader level, using a common DTD for developing information
>makes sharing or exchanging information more feasible and
>easily accomplished. If RayComm publishes an XML DTD for
>topic summaries, and people who contribute summaries use the
>DTD, 75% of Deb's maintenance work can be automatically
>eliminated. This is a real-right-now application.

Yes. In fact, using OmniMark's pattern matching facilities, she could write
an up-translate program that would apply the DTD to summaries which did not
use it. Similarly, she could use OmniMark's down-translate facilities to
translate the XML tagged summaries to HTML for the web. She would find
OmniMark both easier to use and more flexible than any of the client side
solutions available today.

>>The whole point of an SGML or XML compliant
>>application is that it does not have a DTD in it, but that it can read and
>>understand any DTD fed to it.
>
>Exactly! That's why you provide a DTD that describes your data, and
>the data, and a style sheet to format it. And that's something that
>I think we'll be doing and viewing in Netscape Communicator before
>the end of this year.

Exactly back at you. But guess what a style sheet is: its a processing
application. Both CSS and XSL are programming languages. They are not
complete or particularly powerful languages, but they are languages, and the
style sheets you write in them are, in fact, computer programs.

The problem is, they are too limited for many applications. CSS works fine
if you have a one to one correspondence between XML tags and presentation
styles. But this will seldom be the case. For instance, paragraph elements
may appear in the body of a document, or in a table cell. What if you want
paragraphs in table cells to be displayed differently? XSL allows you to
vary presentation based on the context of an element, but that is not
necessarily enough either. HTML tables are defined row by row. Suppose
someone comes up with an XML DTD that defines tables column by column. Now
you have to rearrange the data in order to display it correctly. This is a
significant programming task. You can't do it in CSS. I can do it in 20
lines of OmniMark. I don't think you can do it in XSL, but that spec is not
final and people seem to be pushing for more processing power.

Anyway, the point is, all style sheets are good for is display. If all you
want is display, there are other alternatives. If you use XML for things
other than display purposes, as you should, you will need to write
processing applications in something other than CSS or XSL in order to
accomplish them.

>If one of our clients
>called today and said that they wanted us to develop a documentation
>set for a vaguely Internet-related product with a five year life cycle
>and a strong need for information reuse and online/Web presentation,
>we'd probably push strongly for XML as an information development
>medium. The basic tools for information development are available
>now, they maintain a higher level of information about the content
>than, say, HTML does, and all signs point to broad reuse and repurposing
>potential. At the worst, a valid XML document can be converted to
>ANYTHING, including Word or Frame, with some fairly trivial
>scripts. And, as more and better tools become available, more complex
>and flexible processing is possible.

Well, you already have all the processing power you could possibly want in
OmniMark. There are other languages as well. This is a ten year old
industry, after all. OmniMark's customers are doing very sophisticated reuse
and repurposing today.

>words contained in a good XML-derived markup language are more
>valuable than words contained in HTML (because the significance
>of words enclosed in <ANSWER> tags is clear, while the significance
>of words in <B><I> or <H3> tags is not).

Yes, authors can express their purpose more clearly with well named tags.
But while browsers know how to display <b>, <i>, and <h3>, they don't know
how to display <answer>. So some processing application needs to do one of
two things: either tell the browser how to display <answer> tags, or
translate <answer> tags into standard HTML tags that the browser does know
how to display. This is not meant as a discouraging remark. One of the real
values of XML is that it is media independent. When the next-great-thing
comes along, you will simply change your XML processing application to
format information for it -- no reauthoing of the data. BTW, this is one
reason I prefer server side solutions. If the next big thing does not
support client side CSS or XSL, both of which a web specific, you will have
to learn a new language from scratch to create brand new processing
applications. With server side solutions written in OmniMark you just tweak
your existing code in a language you know and produce output for
next-big-thing.

>Given your employer (and some nice white papers on the site
>with your name on them), I can see your emphasis on processing
>applications--but the real significance of XML is information
>focused, not processor focused.

Well, really, its information processing focused. Neither one works without
the other. The significance of XML is that it enables companies like
OmniMark to create programming languages, like OmniMark, that make it easy
to do sophisticated information processing. You should adopt XML because
those sophisticated and powerful information processing tools are available
to you, and that lets you concentrate more on the information development,
knowing that you can do sophisticated things with your XML tagged
information.

>Processing application? That's a waiting game.

Not at all. The processing applications, or rather, the tools to create
them, are here. They predate XML by several years. Structured editors are
another question. They have a long and not very successful history. Most
SGML seems to be created either by up-translation of direct tagging. XML
does not lend itself as well to direct tagging as SGML (the tagging is more
verbose), so we'll have to see what develops. There will need to be a really
good UI breakthrough, though, to create a broadly useful structured editor,
if the history of SGML editors is any indication.
---
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