RE: Single sourcing and whether XML is a pig or a cat

["Mark Baker" <mbaker -at- ca -dot- stilo -dot- com>]

Bill HALL wrote:

> For most uses, even in technical writing XML has the advantage that ever
> more (and more powerful) tools are coming on the market and are becoming
> cheaper to buy thanks to the market competition. This is an advantage
> not to be sneezed at.

Absolutely true. However, this only means that in order to use a particular
tool at a particular stage of your process you need to transform your
content into the format that that tools supports. You can, and should,
choose the best tool for each stage of your process, and transform your data
accordingly. For example, you can write in SGML or XML. You can use TeX or
XSL-FO for formatting. Whichever combination you choose, you have to
transform your content into either TeX or XSL-FO. The difficultly of such
transformations depends on the structure of your content, not on the markup
language used to express that content. And if you decide that an XML based
tool is the best choice for transformations, just pass your SGML through a
normalizer or SGML to XML converter and then use the transformation tool of
your choice. The point is, the syntax of your markup language is a trivial
issue as far as content processing is concerned.

> Tag minimization allowed by SGML is only good for someone who is trying
> to write raw SGML (e.g., HTML, where tag minimization is allowed by the
> SGML DTD that defines its rules), otherwise it can allow sloppy
> structure and does add to the cost of developing SGML applications to
> cope with it.

I don't follow this. The only reason to use tag minimization is because you
want to write raw SGML. This, after all, is what markup languages are for.
Writing RAW XML is tough, which is why I say it is a poor markup language.

If you do write raw SGML you can get sloppy. However, that sloppiness will
be caught by the parser as soon as you validate the document. The exact same
thing is true for XML. In fact, it is even more true, because the chance of
your failing to supply every end tag is very high.

But if you don't write raw SGML, how can you get sloppy structure? A
structured editor shouldn't let you  create invalid structures, at least not
without warning you. Where do you get sloppy from?

And the point needs to be made that if you are not writing directly in a
markup language it is hard to justify using one. The whole point of a markup
language is that it is human writable and machine readable. But if human
being are never going to write it, what's the point? Markup languages are
verbose and hard for machines to process. The encoding is inefficient and it
often difficult to interpret white space correctly. If you never want human
beings to write the markup, why not choose a generalized binary encoding
that will be more efficient to transmit and process?

> However, the one difference between SGML and XML which has proved very
> important to the design of our DTD's is the fact that SGML allows
> exclusions and inclusions. ... XML's rules
> specifically prevent the approach we used.

This is another area in which it is plain that SGML was designed for
document authoring and XML was not. The virtues and vices of exclusions and
inclusions have been debated forever, but they are clearly a feature
designed for document authoring, and not one you would ever contemplate
including in a  data encoding language like XML.

This whole debate began because I mentioned that we used SGML rather than
XML because of its superior authoring capabilities. A lot of the counter
argument has been focused on other issues -- such as tools -- and seems to
be based on the assumption that one has to choose either SGML or XML to the
exclusion of the other. You don't. Markup languages are just tools. You
choose the best tool for the job. In our systems we used SGML, XML, BNF, and
a number of ad-hoc encodings that suit our needs for particular purposes. We
transform data between these formats as needed.

Tools should serve people, not the other way round. You should not accept an
inferior authoring format just for the sake of some processing tool. Make
technology work for you, not the other way round. Bill uses SGML for its
inclusion/exclusion capability. I use if for its tag minimization
capability. For both of us, it is simply the right tool for the job. Don't
be a tool purist. Use what works best for the job at hand.

---
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 TRIAL NOW AVAILABLE!

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.