Re: [xml-dev] The triples datamodel -- was Re: [xml-dev] SemanticWeb permathread, iteration n+1

[Henrik Martensson <henrik.martensson@bostream.nu>]

On Tue, 2004-06-08 at 15:15, Elliotte Rusty Harold wrote:
> At 8:40 AM +0200 6/8/04, Henrik Martensson wrote:
> 
> 
> >As in having people die in munitions accidents, you mean, because that
> >is the kind of thing that happens when automated systems mess manuals
> >up.
> 
> I can see a possibility of this; for instance marking something as a 
> CAUTION or a NOTE instead of a WARNING. However, more often than not 
> the real problem is not that the user mistyped a tag or invented a 
> new tag. It is that they used a valid but wrong tag for the 
> information. For instance, they put the warning in a  PARA instead of 
> a WARNING.

I agree that this is a very common problem.

In the corporations I work with most of these problems could be fixed by
having an editorial process in place. Something similar to what book and
magazine publishers have, but assisted by XML tools and techniques.

Unfortunately, though a documentation department is, or should be, a
kind of publishing house, few corporations take that view. They spend a
lot of effort on custom software, and very little effort on people,
believing that automation will solve all of their problems. It won't.
(Well, maybe some day, but that is a long way off.)

To some extent it is possible to build systems that guide authors when
writing technical documents. For example, in my work I use:

* Context based, dynamic help (tooltips, element and attribute help
  a lá XMetaL, etc.)
* Real time, or batch, analysis of document content and markup
  (including of course, automated correction of bad markup)
* Lots of help dialogs for entering links, validating
  filter specifications, automated software for generating
  ID numbers, etc.
* Document validation
* Document statistics
* Online documentation (Windows help, HTML based help)

Document validation is just one of the tools in the kit, but I would not
give up any one of them. They are all indispensable, though of course I
don't use all the tools and techniques in every situation.

> 
> Even more fundamentally, the real problem here is the necessity of 
> the warning in the first place. Most properly designed systems 
> (munitions may be an exception) should not be able to kill people. 
> There should be nothing in my toaster, computer, or microwave oven 
> that can injure me short of dropping it on my head from a high 
> building. This should be true regardless of what the manual says.

Cars get people killed every day, and I do a lot of work in the
automotive industry. I have done a lot of work in telecommunications
too, and malfunctioning telecommunications systems, from phones to
exchange systems, can also get people killed.

A malfunctioning computer in a hospital can cause a lot of damage, so
can an air traffic control system on the fritz. A less serious computer
glitch can kill a bank account, or block Internet access. (The latter is
what kept me from the mailing list for a couple of days.)

BTW, I haven't been electrocuted by my computer, or fried by a microwave
oven, but many years ago I had a toaster accident. A very painful
experience. Those things can be lethal...

Then of course there are other kinds of risks: injury, financial risk,
loss of work, loss of data integrity...

All of these risks have to be factored in when choosing a development
strategy. Circumstances vary a lot, so there is no "correct way" of
developing XML systems in general. Some methods are more, or less,
appropriate for a given set of circumstances, that's all.

/Henrik