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.
> SGML may be the grandfather of
> markup, but I think it died a death some years ago.
> This does not mean that it is without merit. Just that
> it is dead as far as the technology curve goes.
Yes and no. There is not a lot of development going on in the SGML space,
but there are still lots of tools available, both commercial and free. You
can certainly work in SGML if you want to. And if you need to use an
XML-only tool for some phase of your process, you can easily normalize your
SGML and push it through the XML processor. But remember that the only bit
of the technology curve that really differs between SGML and XML is the
parser itself. Want to use XSLT to process SGML? Fine, just plug an SGML
parser into your XSLT processor instead of an XML parser. Everything else
will work fine.
> An example would be if you want a Web Browser to
> automatically parse and transform your document on the
> client side. No server side processing. SGML does not
> support this,
Just a quibble, but it is the web browser that is failing to provide support
here, not SGML.
> but with XML a simple stylesheet
> processing tag in the head of the XML document and the
> page is automatically transformed to HTML in the
> browser.
And if you author in SGML, to make life easier for authors, then all you do
to deliver to the web is to normalize your SGML document, at which point it
will parse just like XML. If using SGML gives you advantages on the
authoring side you should not abandon it just to avoid a simple markup
normalization process as part of delivery. This would be just about the
lightest piece of output processing you would have in your entire publishing
system.
> So in terms of the technology available today, very
> little new development takes consideration of SGML.
> While with XML this is the direct opposite.
Like I said, SGML is superior for authoring. For everything else you can
either plug an SGML parser in place of an XML parser, or normalize the
markup and use the XML tools. So while what you say about tools is correct,
it is no reason not to use SGML.
---
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.
