Lists Home |
Date Index |
- From: Ketil Z Malde <email@example.com>
- To: Marcus Carr <firstname.lastname@example.org>
- Date: 28 Jun 1999 17:03:53 +0200
Marcus Carr <email@example.com> 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
> 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
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
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:firstname.lastname@example.org
Archived as: http://www.lists.ic.ac.uk/hypermail/xml-dev/ and on CD-ROM/ISBN 981-02-3594-1
To (un)subscribe, mailto:email@example.com the following message;
To subscribe to the digests, mailto:firstname.lastname@example.org the following message;
List coordinator, Henry Rzepa (mailto:email@example.com)