Re: Moving to SGML, take III

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

Geoff Hart wrote


>"Easy" is a very relative thing. Whether or not you feel that I
>exaggerated in describing SGML as the next best thing to rocket
>science, the point is that it's significantly more demanding than
>HTML.

But HTML is SGML. Writing in an SGML tagging language is as easy as writing
in HTML -- because HTML is an SGML tagging language.

>The difficulty starts with defining an adequate DTD: anyone can
>write messy but functional HTML, but a sloppy DTD isn't worth the
>effort.

Your mixing up two very different things here. First there is designing a
tagging language and then there is writing in a tagging language. To say
writing HTML is easier than writing a DTD is like saying that driving a Ford
is easier than designing an automobile.

Designing an SGML or XML tagging language is as hard or as easy as the
complexity of the data structures you want to express makes it. Desinging
simple things is easy, designing complex things is hard.

Once the language is designed, writing a DTD for it is a simple and straight
forward matter.

Writing in a tagging language that has already been defined is easy.

>Creating a document that conforms is relatively easy at that
>point, particularly with a proper authoring tool. Without one...
>well, let me revise my statement that it's like writing raw RTF.
>A better analogy would be writing WinHelp files by hand (i.e.,
>handcoding the footnotes instead of letting RoboHelp do them for
>you). It's certainly easy enough with some practice, but it's not for
>the fainthearted or careless.

Simply not true, as the evidence of HTML convincingly demonstrates. People
can and do pick up HTML easily and use it with very little effort. There is
no reason this should not be true for other tagging languages, unless they
are really badly designed.

>With the caveats that learning to create useful DTDs isn't nearly as
>easy as you're suggesting and that identifying the 20% that you will
>use to do 80% of your work isn't trivial, I'll accept that without
>further quibble.

I have to reject both caveats. Designing complex DTDs is complex. Designing
simple but useful DTDs is simple. Identifying the 20% of SGML that you need
to 99% (not 80%) of everything you could reasonably want to do is easy. Here
it is:

Take XML.
Subtract XML:SPACE and XML:LANG
Subtract ID/IDREF
Add Shortrefs
Add tag minimization

Viola!

><<Writing RTF by hand to build a win help application would be
>virtually impossible. On the other hand, one could fairly easily
>create an SGML language for this purpose that would be dead simple to
>write in. The all you would need to do would be to write an OmniMark
>program to translate that SGML language into RTF for the help
>compiler.>>
>
>Do I sense an impending product launch?

We make the tools that let other people do projects like this.

The difficulties surrounding SGML are commonly misunderstood. (Hence the
vehemence of my reply to your assertions on the subject ;-) ) The tasks
involved and their relative difficulties are as follows:

1. Design a tagging language. Difficulty -- proportional to the complexity
of what you want the language to do.

2. Encode a definition of your language as a DTD. Difficulty -- easy. If you
use proper modeling techniques in your design work, this task is pretty much
mechanical.

3. Write documents in your tagging language. Difficulty -- easy. Naturally
the difficulty is proportional to the complexity of the language, but
fundamentally it is not hard to do. HTML has clearly shown the fallacy of
the idea that authors cannot deal with tags. One of the most common
complaints about WYSIWYG HTML editors is that they don't tag things the way
people want them tagged.

4. Write processing programs to turn your tagged documents into a useful
form. Difficulty -- hard. Understanding markup processing and choosing the
appropriate tools is the key to success.

There is a completely unrelated task that you need undertake only if you are
going to become a high end SGML consultant or write your own SGML parser. It
is completely unrelated to the tasks above.

1. Learn the complete SGML spec and fully understand all the technical
details of all its obscure features. Difficulty -- hard. But so what? You
don't need to know.

---
Mark Baker
Manager, Technical Communication
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


 From ??? -at- ??? Sun Jan 00 00:00:00 0000=