TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
Subject:Re: Help with Docbook From:eric -dot- dunn -at- ca -dot- transport -dot- bombardier -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Thu, 24 Jul 2003 12:26:14 -0400
Jan Henning <henning -at- r-l -dot- de> wrote on 07/24/2003 11:28:03 AM:
> - HTML is not strict. That means that you cannot be sure that any HTML
> you receive follows given formal standards; it also means that you
> cannot be sure how your HTML will be interpreted. XML was specifically
> constructed to avoid that problem, which means that it is much easier
> to contruct autmoated tools for processing XML (and, by extension,
> DocBook).
HTML *IS* strict if you use the strict DTD.
XML isn't any particular tagging language and you can have strict or loose
XML instances that may be easier OR harder to interpret than even loose
HTML.
Any particular instance of XML such as DOCBOOK is only easier to create
automated tools for depending on how permissive the DTD(s) are, how
strictly they are followed, and how generic the DTD is attempting to be.
> - HTML is almost purely concerned with appearance. It does not provide
> for more than the most rudimentary semantics.
Strict HTML isn't so bad. But arguing/discussing semantics in a vacuum
without talking SPECIFIC semantics is a waste of time. I'd actually say
that much of HTML is NOT concerned with appearance if you sick to tags for
headings, lists, paragraphs and the like.
> - HTML is not extensible in a well-defined manner. XML and DocBok are.
XML is extensible because it is NOT a markup language. XML describes how
to create and interpret markup languages. DOCBOOK and other XML
implementations/instances are only as extensible as the designers,
committees, and systems in which the data is used allow them to be.
> Adopting DocBook means adopting XML, specifically, a perticular
> convention based on XML. DocBook offers semantic structure for
> documents because of its XML roots. Word and unstructured FrameMaker do
> not offer this, although an approximation can be achieved given
> carefully contructed templates and extreme discipline on the part of
> the writers.
Adopting DOCBOOK means adopting DOCBOOK. Adopting DITA means adopting
DITA. Adopting my company's implementation means adopting my company's
implementation. All are based on XML standards. The fact that all are XML
does not mean that it is easier to share information amongst these XML
applications than it is to share between Word and FrameMaker. That's what
annoys me about the hype.
Indeed compared to what is written above, DOCBOOK and all that is required
to support it and author in it really only amount to well constructed
templates and decent writers. DOCBOOK is so huge that I doubt that any
proofreading/editing effort is even saved compared to a well run
department approval/editing process. In fact, to justify the development,
transition/migration and support costs of an XML implementation there
should be proof of large savings first.
The tools an analysis of the various XML implementations may be more open
that the RTF standard, but to convert from one to the other still requires
a lot of preplanning or after the fact analysis and development.
The display or use of DOCBOOK in a different editor than the original
requires significant template and style sheet development and possibly
read/write rules. Whether it's CSS, XSL, FrameMaker EDDs, or Adept FOSIs.
Seems to me all too often the drive to XML is based on: I haven't a clue
about it, but it's hot, it's hyped, it's open, hundreds of things are
saying XML, we have to have it!
If the document/information structure model of XML produced in FM is
different from the model used in Word (as the current binary formats are)
then it will be no simpler to share information. Unless both parties are
using the SAME XML implementation. At which point virtually all
extensibility and openness are lost to the requirements of conforming to a
set standard run/written by committee and limited by the least performant
application in the group. Pretty much the same problem you have if you're
trying to share information between Word and FrameMaker users really...
NEED TO PUBLISH FRAMEMAKER CONTENT ONLINE? "Mustang" is a NEW single
sourcing tool for FrameMaker that lets you easily publish your content
online. No macro language required! http://www.ehelp.com/techwr-l3
Mercer University's online MS Program in Technical Communication Management:
Preparing leaders of tomorrow's technical communication organizations today.
See www.mercer.edu/mstco or write George Hayhoe at hayhoe_g -at- mercer -dot- edu -dot-
---
You are currently subscribed to techwr-l as:
archive -at- raycomm -dot- com
To unsubscribe send a blank email to leave-techwr-l-obscured -at- lists -dot- raycomm -dot- com
Send administrative questions to ejray -at- raycomm -dot- com -dot- Visit http://www.raycomm.com/techwhirl/ for more resources and info.
