OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] XML-appropriate editing data structures

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



News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS