[
Lists Home |
Date Index |
Thread Index
]
Elliotte Rusty Harold wrote:
> At 9:08 PM -0500 4/7/04, Bob Foster wrote:
>
>> However, the expectations of a modern XML editor are set by the
>> features of modern programming language editors:
>
>
> As someone who wrote a 1200 page book, completely in XML in the very
> high-performing jEdit, and another 300 page book in the XML editor
> known as OpenOffice, I have to question a lot of your assumptions
> about what features a modern XML editor should have. For instance, I
> find outline view completely useless. It seems to get into editors
> only because modern GUI toolkits make it trivial to implement (at
> least until documents stop being small), not because users actually
> want to edit their documents as outlines.
>
> I think an editor that began by asking how users actually want to edit
> XML data would avoid a lot of the performance problems you've
> encountered, simply by not implementing unnecessary features. I see no
> reason that the feature set of an XML editor should be a copy of the
> feature set of a modern programming language editor. I want very
> different things when I'm editing XML than when I'm writing code. They
> are not the same task. They are not even close.
Well yes, maybe. I think it depends a lot on what *kind* of XML you are
working with. Certainly when there is a lot more text than structure you
want something closer to a text editor. When there is a lot more
structure than text you want something closer to a form based editor.
The fact that there is this range of application makes producing a good
*general purpose* XML editor very difficult.
I do agree with Bob Foster's comment about the *expectations* being set
by modern language editors, especially as we get closer to the form
style of editing. We expect more and more help from the tool.
Come to think of it, this probably follows on with performance as well.
DOMs which contain a lot of structure relative to text consume a lot
more memory, and that is to some extent reasonable because they have to
model more information. But the current generation of DOM
implementations (especially the Java ones) seem to have excessive needs.
v/r
Mark
|
