Re: XML & Technical Writers...

[Mark Baker <mbaker -at- OMNIMARK -dot- COM>]

Simon North writes


>For 'extensible' read 'adaptable'. XML's extensibility is not
>restricted to the (more obvious) point of addding element tags; XML
>is far better suited than either SGML or HTML for a distributed
>environment. For example, it can deal with MULTIPLE DTDs, it can
>merge attribute definitions from multiple sources, it can have local
>and remote DTD subsets allowing, for example, general template DTDs
>with local adaptions. It understands web addresses (URLs).

At the risk of sounding like a broken record, XML can't do any of these
things -- XML processing applications can do these things. (And so can SGML
processing applications.)

>Better still, XML can do translusions (think in terms of 'virtual
>documents' composed from linked inclusions of other documents). Want
>to make a dynamic index of a manual? create a 'hub' document that
>pulls in the TITLE and AUTHOR elements from all the documents. It
>goes further, links can be external to the source document (gone is
>HTML's brain-dead idea of hard wiring the link into the source
>document). You can link to READ-ONLY material. You can link to BLOCKS
>of text, not just a simple target somewhere in the document.

Again, applications can do this. XML provides a standard for defining the
markup on which the applications act. So does SGML.

>On a more technical side, XML can be loosely though of as being
>object-oriented SGML. The primary object in XML terms is an 'entity';
>this can be a document, it can be an element, or it can be a piece of
>data. Now, couple this with the DOM (document object model), XML-Data
>and RDF (resource definition format), plus other efforts (XAPJ,
>SAX) to define an API (application programming interface) for XML
>objects and you have the basis for bringing SGML into the 21st
>century (don't forget that SGML still has its roots firmly embedded
>in the 1960's concepts of document/text processing --- if you
>doubt this, consider the sequential processing nature that lies
>at the very heart of SGML).

This confuses XML with a series of of other initiatives and proposed
standards which might work with XML, but are not XML. (I think you are
really talking about XLL here.) XML is not different in nature from SGML.
SGML has a similar cluster of hanger-on standards like DSSSL and HyTime, but
they are not nearly as widely adopted or well supported as SGML, largely
because there are better ways of doing the things they do. No one should
suppose that XLL, XSL, XML-data, or the rest of the pack are part of XML.
XML does not need any of them. They will succeed or fail in the marketplace
on their own merits as parts of information processing architectures.
Commiting to XML does not in any way commit you to any of the rest of the
proposed standards, especially not the processing ones.

>What does it mean for tech writers? 2 words 'the future'. In any
>enviroment where computer processing (and in particular database
>applications), information and the Internet meet; there is an area
>where XML will excel over both HTML *and* SGML. The implications for
>technical documentation should be pretty obvious, it will simply
>revolutionize the way in which we publish electronically.

There is a revolution to be had, but that revolution is content management.
XML is one of the enablers of content management. Don't confuse the tool
with the solution.

---
Mark Baker
Manager, Corporate Communications
OmniMark Technologies Corporation
1400 Blair Place
Gloucester, Ontario
Canada, K1J 9B8
Phone: 613-745-4242
Fax: 613-745-5560
Email mbaker -at- omnimark -dot- com
Web: http://www.omnimark.com