[
Lists Home |
Date Index |
Thread Index
]
Henrik,
The features you ask for (block vs. inline, tables, images, indenting,
spacing) can not be automatically detected by reading a user-written schema.
I think you're confusing a general-purpose XML editor with a very specific
XML editor tailored to specific XML vocabulary(s). I guess I just don't see
this as a 'programmer' vs. 'author' issue.
I think a step to alleviate the problems you mentioned would be for
general purpose XML editors to provide a 'preview in browser', 'run
stylesheet' and/or 'run XML processing pipeling' options.
-----Original Message-----
From: Henrik Martensson [mailto:henrik.martensson@bostream.nu]
Sent: Friday, April 09, 2004 8:56 AM
To: Bob Foster
Cc: XML Developer List
Subject: Re: [xml-dev] XML-appropriate editing data structures
On Thu, 2004-04-08 at 16:46, Bob Foster wrote:
> It seems quite likely that the utility of the outline view has
> something
> to do with the nature of the document. If you write very large
> DocBook-like documents, the outline view is pretty much useless; all it
Outline views are _particularly_ useful when editing large documents,
provided that you can hide minor block elements, such as paragraphs,
admonitions, tables, etc.
One thing that I haven't seen in an XML editor yet, but that would be very
nice, is an outline view that works over multiple files.
After reading several messages in this thread I feel a rant coming on, but
I'd like to say this first:
As a programmer, I appreciate the difficulties in creating an XML editor
that is fast, provides all the features necessary for structured authoring,
and manages to format a document for onscreen display. I won't pretend to be
half as good a programmer as the people who have written the XML editors I
am about to trash in the following paragraphs. I am going to look at the
issue solely from the viewpoint of a professional technical writer.
Now, the rant. If you are under 18, or have a high blood pressure, please
skip this:
As a writer I have a hard time understanding why most of the current crop of
XML editors have user interfaces that are a lot worse than my old SGML
editor. (WordPerfect with an SGML plugin.) Nor can they measure up to other
old time SGML/XML tools, such as ADEPT Editor,
FrameMaker+SGML, Documentor, and others. (Yes, I know that from a
developers point of view, some of these were just horrible. Some were not
exactly ideal writng tools either, it's just that they seem better than many
of the things that are around today.)
Most of the current crop of XML editors, XMetaL and Arbortext Publisher are
exceptions, seem to be little more than text editors with syntax
highlighting. This is not what I want in an authoring tool that I am going
to use several hours a day, every day. Text editors with syntax highlighting
may suit programmers, but that is very different from being suitable for
authors.
XML editors must make it easy to write and structure documents. Context
sensitive element dialogs and validation are necessary, of course, but they
are not enough, not by a long shot.
For example, while you do not need the sophisticated styling of a word
processor or DTP program, the ability to format block elements and inline
elements differently is absolutely vital. You also need to distinguish
titles visually, there must be support for table formatting, etc. Documents
often contain images, or other embedded media objects, so support for that
is also a necessity.
Of course the features listed above are a bare minimum. In an editor for
professional use I also expect things like change bars, integration with a
DMS, a preview of formatted documents (limited use, I know, but quite often
I operate within those limits), and a host of other features.
As for tag coloring: It is a good thing to make tags visually distinct, but
treating tags as text with a different color is not good enough. For
example, it should not be possible to edit the tag name, particularly not in
such a way that the document does not validate. My personal preference is
for editors that denote tags with some sort of graphical symbol. Editors
that just lock the tags so they can't be edited are technically sufficient,
though they may lack a bit of visual appeal.
I have seen "XML editors" that rely on the insertion of line breaks and
indentation with whitespace to format documents on screen. This is just bad.
For one thing, when you open a document created in another XML tool, there
may not even be any line breaks or indents in the document. Editing a 300 kB
XML document that appears on a single line in an editor is no fun.
Most of the discussion in this thread has been about XML editors from the
point of view of developers. Quite natural, I suppose. This isn't the
xml-author mailing list. However, it seems to me that from a users point of
view, the average quality of structured authoring tools have been lowered in
recent years. The best XML authoring tools are those that have been around
since the days of SGML. There are only a few of those left. The new
generation tools just is not as good.
Rounding off the rant by widening my perspective a bit, I am aware that
there are advantages to the newer tools. Price is one thing. Portability is
another, because many of them are written in Java. However, if the tools
aren't good enough for everyday use, portability does not matter. (I still
haven't found a really decent XML editor that runs under
Linux.)
I believe that looking at text editors and IDEs, and using them as a basis
for creating XML editors is the wrong thing to do. It would be more useful
to look at the current leaders in XML editing, i.e. XMetaL and Arbortext
Epic, and figure out how to beat them.
/Henrik
-----------------------------------------------------------------
The xml-dev list is sponsored by XML.org <http://www.xml.org>, an initiative
of OASIS <http://www.oasis-open.org>
The list archives are at http://lists.xml.org/archives/xml-dev/
To subscribe or unsubscribe from this list use the subscription
manager: <http://www.oasis-open.org/mlmanage/index.php>
|
