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.
Rigid only in the sense that it has fewer options for defining markup. Not
in the sense that it is in any way stricter in the enforcement of document
structure.
> so it lends itself easier to a wide variety of
> transformations.
Not at all. The only difference between processing XML and processing SGML
is the parser you use. The structures reported by the parser to processing
applications are identical so any transformation you can do on an XML
document you can do an and SGML document. There is no difference in the ease
with which it is done. The only difference is the ease of writing a parser.
And you don't write your own parser.
> The real point to remember was just stated on-list:
> technology advancements are banking on XML, not SGML.
No. The real point to remember is that data representation formats are
essentially ephemeral. You only need them for the duration of the particular
operation you are performing.
The most pernicious idea floating about the XML universe is that everything
should be in XML all the time. It is the equivalent of saying that Frame is
the best tool for writing technical documents so all technical documents
should stay in Frame format all the time and people who want to read
technical documents should buy a copy of Frame.
Data gets transformed into the most suitable form for the next operation to
be performed on it. The point of markup technology is to make it easier to
perform transformations. This means precisely that XML and SGML exist to
enable data to be represented in the best possible format for each operation
at each stage of its life cycle. To insist on all XML all the time is to go
against the very raison d'etre of markup technology.
Use the best format for each operation. For many authoring tasks, that will
be SGML. If you need the data in an XML format for some operation to be
performed on it later, transform it into XML for that operation. If you need
it in HTML or RTF or TeX or FO, then transform it into those formats as and
when you need to.
XML is a really good format for some operation and a really bad format for
others. SGML is the best format for some operations, and not the best for
others. It isn't an either/or decision. Use what works best to solve the
business problem you have on hand. A good solution for a technical
documentation system should probably involve both SGML and XML.
I agree that most people probably will cut themselves off from the benefits
of SGML in the authoring environment, quite unnecessarily so. My fear is
that dealing with XML authoring will be sufficiently onerous that either the
system will be simplified to the point that the benefits are lost, or the
whole system will be abandoned in frustration. XML-only blindness could ruin
the chances for markup technology to succeed in the documentation space.
---
Mark Baker
Stilo Corporation
1900 City Park Drive, Suite 504 , Ottawa, Ontario, Canada, K1J 1A3
Phone: 613-745-4242, Fax: 613-745-5560
Email mbaker -at- ca -dot- stilo -dot- com
Web: http://www.stilo.com
This message, including any attachments, is for the sole use of the
intended recipient and may contain confidential and privileged
information. Any unauthorized review, use, disclosure, copying, or
distribution is strictly prohibited. If you are not the intended
recipient please contact the sender by reply email and destroy
all copies of the original message and any attachments.
RoboHelp for FrameMaker is a NEW online publishing tool for FrameMaker that
lets you easily single-source content to online Help, intranet, and Web.
The interface is designed for FrameMaker users, so there is little or no
learning curve and no macro language required! Call 800-718-4407 for
competitive pricing or download a trial at: http://www.ehelp.com/techwr-l4
---
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.
