XML Editors - Word 2000??

Ketil Z Malde ketil at ii.uib.no
Mon Jun 28 16:10:49 BST 1999

Marcus Carr <mrc at allette.com.au> writes:

>> according to a fixed DTD with a separate style sheet reflecting the
>> formatting, but for general XML documents?  Rather not.

> What might I ask does a general XML document look like? Legislation?
> Database records?  Automotive diagnostic data? Financial transactions?

Yes.  Either.  Any.  All. I guess I should have said "XML documents in 
general", as opposed to working with a fixed DTD.

> People who are drafting XML documents such as legislation are not
> working with the structure,

So they don't know about paragraphs, or references I take it?

> they're working with the content. It is the duty of the application
> designer to support them, not lay bare the system's guts and watch
> them run shrieking into the night.

If you insist that people bright enough to work with legislation are
too stupid to grok the simple context of tags, I would suggest you
underestimate them.  Of course they won't understand it if you do your 
best to hide structure behind formatting.

> Content experts are valued for their knowledge about a particular
> topic, not for being able to read a DTD.

Who said they'd have to?

> I believe that tools such as FrameMaker+SGML or WordPerfect 8.0

My experiences with those tools are kind of mediocre - that could of
course be due to being exposed to SGML first, and the tools later.
The problem is that the tools focus on the wrong end of the problem -
how the document looks when printed on paper - instead of on what the
document *is*.

> Would you hold the same argument about databases?

I would, in as much as I don't think a data entry program should have
rows of buttons to determine fonts, colors and other WYSIWYG stuff
for the various fields instead of labels.

Actually, forms for entering database records is much closer to what
I'd like for SGML input.  I like XEmacs and the psgml-based html-mode; 
on loading a document with the .html extension, the user is prompted
for a title, and presented with a buffer containing a rough framework
of an HTML document, something like

	<!DOCTYPE blah blah>
	     <title>your title here</title>
	     <h1>your title here</h1>
	     (some empty lines)
	  (some signature stuff, last change and a mailto: link)

You don't have to be a genius to work that one out.  And this is
considered difficult and obscure.  If somebody is remotely familiar
with the editor, it's about three minutes to explain where to put what 
information, and why, and off you go - and the built in parser
restricts you to the valid elements and attributes at any point in the 

>> [...] XML using <address>-elements to get italics.

> How would that differ from making an incorrect assumption about the
> semantics of an element in a text editor and then applying a
> stylesheet? 

You mean, somebody actually inserting an element labeled <address> to
contain a license plate number, in the firm belief that that's what an
address is?  That could equally well happen, of course.

The point is that if all you see is italics vs. normal, and you know
about a button which gives you italics, then that button is what
you're going to press.  Sure, people may mistake the meaning of tags,
but they are a) restricted in what context they may appear, and b)
labeled with (hopefully something more meaningful than typographical
information, and c) supplied with a helpful comment in the DTD, which
the editor can display.

> There aren't that many ways of assisting users with element usage,
> but one of the main ones might be requiring validity over
> well-formedness at the authoring stage and do a good job of the
> analysis.

Of *course* you should require validity.  What else would be the point 
of using SGML?  If you want formatting oriented documents with
no guarantee of correctness, it's not hard to find.

> From one Grumpy Old Fart to another...

If I haven't seen further, it is by standing in the footprints of giants

xml-dev: A list for W3C XML Developers. To post, mailto:xml-dev at ic.ac.uk
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:majordomo at ic.ac.uk the following message;
(un)subscribe xml-dev
To subscribe to the digests, mailto:majordomo at ic.ac.uk the following message;
subscribe xml-dev-digest
List coordinator, Henry Rzepa (mailto:rzepa at ic.ac.uk)

More information about the Xml-dev mailing list