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

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

Lani Hardage wrote:

>Actually, XLL (extended linking language, a part of XML) does allow
>reuse rather easily.

XLL is not part of XML, it is part of a group of related standards of which
XML is also a member. XLL does not allow reuse except insofar as it provides
a method for indicating inclusion of one piece of data in another. There are
many other (frankly better) methods. The problem in reuse is not
accomplishing the inclusion, it is making the material suitable for
inclusion.

>And changing formats is also provided for in XSL
>(extended style language, a part of XML): e.g. you can insert tags
>specify which font to use for print, which font for display. And I
>think other output options such as audio and video will also be
>standardized in the near future.

As I said in my last post, XSL is a (proposed) language for developing
processing applications for documents tagged in XML based tagging languages.
It maps elements from the document's language to HTML/CSS elements for
display purposes. As proposed, XSL is a comparatively weak language,
especially when compared to mature and fully fledged alternatives like
OmniMark. And XSL is still just a proposal. There is no complete
implementation. The point is though, that XSL is a programming language. If
you want to display documents that conform to a DTD of your own creation,
you need to write a program to do it. XSL is one tools you could use, but
you still have to write the program.

And, once again, XSL is not part of XML, but one of a group of proposed
standards which includes XML.

>Most technical documentation will only need a DTD, which is not that
>complicated to create. There will probably be standard DTDs created
>for documentation.

There have been standard DTDs for documentation for years: SGML DTDs. Most
major industries have them. Few companies actually use them. But remember
that a DTD defines a language. HTML has an SGML DTD, but we don't say
someone is using SGML when they author in HTML. If we did create a single
DTD for documentation, it would define a specific language (let's call it
TDML for Technical Documentation Markup Language). Now when we use TDML we
are not using XML anymore, we are using TDML. If people write TDML tools,
they will be TDML tools, just as todays HTML tools are HTML tools.
Individuals will not be able to extend TDML without writing their own
processing tools, any more than people today can extend HTML without writing
their own tools. Tagging languages can be usefully extended by those who
write the tools that process them, and not by anybody else. It you want the
freedom to design your own language, you must accept the responsibility for
creating your own processing applications.

>Again, we are not necessarily creating processing apps, just
>documentation. But you can bet that developers will also get into
>creating DTDs for XML, because it means that inventory, ordering,
>accounting and many other apps can be done over a secure,
>platform-independent network. The business applications of XML far
>outweigh the documentation applications.

Perhaps, but none of these things will happen unless people in the
industries concerned write processing applications to do all these wonderful
things.

>As I understand it, when you have a DTD (and any browser you use
>currently has one), you know what the tags mean.

Okay, here's an XML DTD:
<!doctype foo [
<!element foo (bar)+>
<!element bar (#PCDATA)>
]>

Now, tell me what the tag "bar" means. Tell me what the following XML
fragment, based on this DTD, means:

<foo><bar>onion</bar><bar>dave</bar></foo>

A DTD tells you what tags there are and what order they are allowed to be
in. Nothing else.

Current browsers do not have DTDs. For HTML, this would require putting a
complete SGML parser into the browser, which would be expensive and
pointless. Current browsers parse HTML directly without the use of the HTML
DTD, and are much more lenient about markup than an SGML parser would be. In
any case, DTDs describe tagging languages and they accompany the tagged
document, not the application. 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.

>Mark wrote:
>...in itself, XML does not eliminate the
>> proliferation of formats, it contributes to it. (Everybody and his
>> dog can now create their own tagging language.)
>>
>Then why are chemists now able to read and interpret and share
>information based on the DTD for chemistry (and there is one for math
>and one for pharmaceuticals) with the aid of an XML parser?

Because someone wrote processing tools for the markup languages they
created. That's the point: an industry with specific needs creates a tagging
language and a set of processing applications that meet those needs. The
point of XML and SGML is that they provide a standard way of describing the
grammar of a tagging language. This means that the language and the
processing applications can be built using higher level tools that parse
SGML or XML. Building them is very much easier than it would be without
these standards, and the tools based on them, but they must still be built.

>Mark wrote:
>...XML alone will not do much for you.
>
>I'm not convinced. Sorry if I misinterpreted any of your statements,
>and perhaps this will encourage a further dialogue. But I tend to
>agree more with Deborah Ray's enthusiastic evaluation of XML's >potential.

I am not unenthusiastic. In fact, I am very enthusiastic. After all, I have
chosen to work for the company that makes the best XML and SGML programming
tool you can buy (OmniMark). I am an active proponent of content management
systems which use XML/SGML as a vital component. I am simply alarmed by the
general failure to appreciate that the point of XML is that it allows you to
create custom information processing application very much more easily than
if there were no standard. It is custom processing applications that do the
real and exciting work. That is where people's enthusiasm and attention
ought to be focused.

To return to my previous analogy, Esperanto, whatever its hypothetical
virtues, is a useless language because nobody speaks it. English, whatever
its flaws, is a useful language because people do speak it. This means I can
do useful work in English, but I can't do useful work in Esperanto. In the
electronic publishing world, processing applications are the things that
"speak" tagging languages. HTML is useful because Internet Explorer and
Netscape Navigator speak HTML. I can invent a new tagging language if I
want, but until some application speaks that language, it is not useful. The
good news is that it is easier than ever to write useful processing
applications for tagging languages based on XML and SGML.
---
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