XML Editors - Word 2000??

Tue Jun 29 01:55:27 BST 1999

Ketil Z Malde wrote:

> > 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?

Wow, you are grumpy. Do I really need to rephrase that sentence?

> 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.

It's not a matter of intelligence, it's a matter of focus. If you're paying
a lot of money to obtain someone's expertise about the law, it's not
practical (and may even be financially foolish) to pay them to fiddle around
with tags. What would you say to the legal expert who said that anyone smart
enough to understand XML tagging should be capable of writing legislation?
Why do we assume that just because we have a need for XML data, all sorts of
different professions are going to accommodate us at their own expence?

> 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*.

I'm not saying that it's the right way to go in all cases, just that I'm
sick of having people ask if they can author in Word and me telling them
they have to use MultiEdit or Emacs. They don't want to hear it and I don't
want to say it. There is a strong correlation between what a document looks
like on paper and what it is - as paper publishing is still inevitable in
some industries, they are often nearly the same thing. It won't work
maintaining that I've been suckered by applications - my experience in SGML
predates any WYSIWYG tools by many years and even now I use MultiEdit over
any application. Years of banging my head against the wall have cured me of
the urge to persist with that as a solution for clients (and left me with a
near-constant ringing in my ears...)

> 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>
>         <html>
>           <head>
>              <title>your title here</title>
>           </head>
>           <body>
>              <h1>your title here</h1>
>              (some empty lines)
>           <hr>
>           (some signature stuff, last change and a mailto: link)
>           </body>
>         </html>
>
> 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
> document.

Wunderbar! And you get valid HTML out the other side, you say? Have you
tried modifying it for DocBook? Ironically, FrameMaker+SGML will allow you
to edit your data in a visual tree-based interface, though I don't think
much of it personally.

I find it interesting that you are looking for an application that will help
you create good data, but apparently begrudge others the same thing. Your
preferred interface involves the use of raw tags; I'm maintaining that some
others may want even more help. I use MultiEdit - by your logic, I should be
running you down for looking for a guided syntax editor. It doesn't have to
be ugly to create correct data.

> 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.

I think you're considering users in too narrow a band - they aren't all
bereft of any understanding about structure. They always understand what
you're trying to achieve, they just want it to be easy for them to use. An
application is an interface to the structure that doesn't interfere with the
content. An application designer is the one that tries to ensure that both
objectives are satisfied.

> > 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.

You're mixing up what I'm saying - well-formedness doesn't equate to format
oriented documents and the subject still says "XML Editors". I'm saying that
validity allows you to guide the user by restricting the available elements
whereas well-formed doesn't.

--
Regards,

Marcus Carr                      email:  mrc at allette.com.au
___________________________________________________________________
Allette Systems (Australia)      www:    http://www.allette.com.au
___________________________________________________________________
"Everything should be made as simple as possible, but not simpler."
       - Einstein

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)