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: Why WYSIWYG for XML??? From:eric -dot- dunn -at- ca -dot- transport -dot- bombardier -dot- com To:"TECHWR-L" <techwr-l -at- lists -dot- raycomm -dot- com> Date:Wed, 19 May 2004 10:17:14 -0400
> Bill Lawrence wrote:
> +++
> I note (with no small amount of consternation) that many
> writers, when
> considering going to XML, are looking for WYSIWYG
> authoring tools. In
> my experience, using WYSIWYG tools are a real barrier to
> getting writers
> into the mindset of semantic markup versus visual layout.
> +++
Am I the only one that sees much of the discussion that has followed as a
pointless and off-the-mark polarised discussion about two pointless and
equally undesirable alternatives?
WYSIWYG vs. Non-WYSIWYG is surely NOT the choice between using a DTP
package using styles based purely on formatting vs. using a text editor
and hand coding element tags. I mean, come on! Those that have succumbed
to participating in this argument are either simply being contrary or they
have severe logic and perception problems. (IMO)
Even before moving to structured documents it is often a better idea to
have a production template that is different from your final ouput(s).
Surely it isn't too much to understand that while you may not be seeing
what will appear (design wise) in the final output, you WILL be working in
a structured environment that simplifies the tagging process, allows you
to evaluate structure, and uses design to visually highlight/indicate the
tagging and structure that is applied.
If you are of the camp that believes WYSIWYG should represent the final
output, forget it. In many cases the final output may be a combination of
source documents that will only be available at time of production. In
other cases the final output may not even be decided at the time content
creation is commenced. Or, as a major reason for structured/XML/SGML
documents is reuse and information interchange, the producers of the
content may never be responsible for the final deliver or content may be
reused in a completely different format from the original. The WYSIWYG
environment should represent not the final output, but it should
accurately convey to the author/editor the semantics of the information.
That code is tagged as code, headings as heading, sections as sections,
callouts, part numbers, etc., etc. In final output ALL of these things may
be formatted identically, some may be dropped depending on the output. But
for the integrity of the information the author/editor has to see not that
the test is 14pt bold but that the text is a heading, not that a number is
in parentheses but that the number is a callout. That's not to say that in
an ideal workflow, the final assembled output isn't checked.
If you are of the camp that believes that tagging should be done by hand,
get real and catch up with the times. I mean honestly. Given the
technology today, why on earth should someone be staring at a screen full
of ASCII text trying to figure out what level their <title></title> is?
Given Near&Far Designer and the ability to design DTDs graphically, why on
God's green Earth should I fall back to coding DTDs by hand in text files?
If FrameMaker, Epic, Authentic, or even MSWord can show me the structure
and allow me to manipulate it using drag-and-drop and at the same time
give me a formatted environment to work in, why on Earth would I choose to
work with angle brackets?
Even the Arbor Text gang who try and bamboozle prospective clients by
claiming to work in "pure" XML/SGML don't give you a tool that forces you
to work with brackets and tags.
SEE THE ALL NEW ROBOHELP X5 IN ACTION: RoboHelp X5 is a giant leap forward
in Help authoring technology, featuring Word 2003 support, Content
Management, Multi-Author support, PDF and XML support and much more! http://www.macromedia.com/go/techwrldemo
>From a single set of Word documents, create online Help and printed
documentation with ComponentOne Doc-To-Help 7 Professional, a new yearly
subscription service offering free updates and upgrades, support, and more. http://www.doctohelp.com
---
You are currently subscribed to techwr-l as:
archiver -at- techwr-l -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.
