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: Giving up on XML From:eric -dot- dunn -at- ca -dot- transport -dot- bombardier -dot- com To:techwr-l -at- lists -dot- techwr-l -dot- com Date:Thu, 15 Mar 2007 09:33:37 -0500
> "XML" is specifically be the name of a markup language,
> but as a technology it cannot be divorced from its tools.
To be pedantic, XML is NOT a markup language. HTML, DocBook, and DITA are
markup languages and have implementations using different tools.
It is impossible to address an implementation issue without knowing what
tools are involved.
> Talking about "XML as a language" as if it is something
> that can stand apart from the tools needed to work with it
> is like talking about HTML without its authoring tools or
> browsers.
Actually, that's what I find most disappointing about the discussion on
TECHWR-L with regards to XML. When discussing HTML, the professionals on
the list seem to have no difficulty what-so-ever separating tools issues
from underlying HTML language issues.
> In both cases, the "user experience" is dependent
> upon the quality of the tools required to work with it.
True. But if you were forced to use notepad to author HTML, you wouldn't
be slagging HTML. Nor do list members blame HTML for Frontpage or
Dreamweaver foibles.
> In the context of a discussion of *working* with XML, I
> would submit that it is you who does not seem to understand
> the relationship of the language and the available tools.
Well actually, if that is your contention can you point to any part of
this discussion where the actual tools were brought up?
> They are joined at the hip, and talking about either without
> the other is just pointless.
Which really has been a big part of my argument. Stop complaining about
XML when your problem is with the tools, implementation, or specific XML
based language.
> I recall a similar discussion a long time ago on
> a different forum in which someone maintained
> that designing websites in HTML source required
> a different way of thinking than doing a print page
> layout in WYSIWYG apps like Quark or Pagemaker.
> That was certainly true at the time because HTML
> tools like Dreamweaver had yet to come along.
There still seems to be a fundamental comprehension problem in that
argument. It's impossible to have a universal WYSIWYG XML tool such as
Dreamweaver. If you're using an XML compliant HTML DTD, Dreamweaver *IS* a
WYSIWYG XML tool.
Various WYSIWYG tools do already exist for other standard DTDs. DITA,
Docbook, etc.
> The
> question is, will we all "switch to an XML tag-based
> environment from a WYSIQYG environment," or
> will XML continue to be the stomping ground of
> early adopters and turnkey solution sellers until
> its tools adapt to those who aren't going to switch
> to a different working environment?
That argument makes the preposterous assumption that we *ALL* work in the
same type of work environment now or in the past. We don't. Look at the
number of help formats, delivery options, and tool chains in use.
Some will adopt XML, some won't. Of those for whom XML has an advantage or
is otherwise a requirement, some will adopt available tools and existing
XML implementations (DITA, Docbook) as-is with some tools cheap and
generic others expensive and specialised. Others will adapt available
tools to their needs and adapt the implementations (Docbook lite,
specialised components for DITA, sub sets of ATA). Others still will
develop from the ground up.
As is the case now regardless of the domain or technology under
discussion. Even "simple" production of hard copy considering the
different levels of master of the tools, templates, and scripting
languages that can be used.
> If a need arose that justified the expense
> of implementing a turn-key structured document
> solution that didn't require every writer on staff to
> become a programmer, that would be different.
For someone who seems quick to lambaste XML boosters for over hyping the
benefits of XML, you could scale back on the negative hyperbole.
As quills -at- airmail -dot- net has already pointed out, once implemented few of the
writers need any knowledge of the internals. In the large department I
work in, none of the writers know how to create or edit DTDs or EDDs. All
they do is tag in FrameMaker. The Document Analysts deal with structure
and work flow, IT develops and supports the back-end and rendering.
What people are usually the most upset about is that they can't re-format
to their hearts delight or that the WYSIWYG they work with isn't the
format as assembled and delivered to the client.
For comparison, how many writers absolutely need to know how to create a
Word or FrameMaker template in a department? Only one really. The rest
just apply formats. Or, how many people in a department need to know the
inner workings and setup of Robohelp or Webworks to generate help files?
How many need to know the inner workings of ASP, PHP, PERL, or what ever
other technology/language is used by the server for the corporate webpage
content?
This e-mail communication (and any attachment/s) may contain confidential
or privileged information and is intended only for the individual(s) or
entity named above and to others who have been specifically authorized to
receive it. If you are not the intended recipient, please do not read,
copy, use or disclose the contents of this communication to others. Please
notify the sender that you have received this e-mail in error by reply
e-mail, and delete the e-mail subsequently. Please note that in order to
protect the security of our information systems an AntiSPAM solution is in
use and will browse through incoming emails.
Thank you.
_________________________________________________________________________________________________________________
Ce message (ainsi que le(s) fichier/s), transmis par courriel, peut
contenir des renseignements confidentiels ou protégés et est destiné à
l?usage exclusif du destinataire ci-dessus. Toute autre personne est par
les présentes avisée qu?il est strictement interdit de le diffuser, le
distribuer ou le reproduire. Si vous l?avez reçu par inadvertance,
veuillez nous en aviser et détruire ce message. Veuillez prendre note
qu'une solution antipollupostage (AntiSPAM) est utilisée afin d'assurer la
sécurité de nos systems d'information et qu'elle furètera les courriels
entrant.
Merci.
_________________________________________________________________________________________________________________
Create HTML or Microsoft Word content and convert to Help file formats or
printed documentation. Features include single source authoring, team authoring,
Web-based technology, and PDF output. http://www.DocToHelp.com/TechwrlList
Now shipping: Help & Manual 4 with RoboHelp(r) import! New editor,
full Unicode support. Create help files, web-based help and PDF in up
to 106 languages with Help & Manual: http://www.helpandmanual.com
---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot-
