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 ]

Bryce K. Nielsen wrote:
 > ----- Original Message -----
 > From: "Henrik Martensson" <henrik.martensson@bostream.nu>
 >>I do not think we will come to an agreement in this thread.
 > I disagree ;-)
 > We can come to an agreement, that being that each XML user will have 
 > own preferences on how they prefer editing their documents, just like 
 > editors.

Agreement is the wrong word, perhaps, but a certain consensus has 
emerged from this discussion (which I personally have found very 
helpful) and I will try to summarize it.

Some people prefer editing XML in text form. These people don't mind the 
editor providing certain amenities (I didn't hear anyone speaking out 
against syntax coloring, for example, though now that I've said it 
somebody probably will) *provided* they don't get in the way (add 
overhead, slow down editing, try to outsmart the author).

Others find XML text too far from the final result. E.g., if one is 
writing books, one may prefer to edit a simile of a book, ditto if one 
is creating graphics, writing music, designing a house, filling out a 
form. To call this a desire for "WYSIWYG" would, I think, be misleading. 
What people in this category seem to say is that they need the ability 
to visualize the "transform target" of the XML while they are writing 
it. If they can get the whole job done by directly editing the target, 
so much the better; but simultaneous visualization is a baseline 
requirement. Len, if I understood him correctly, suggested that an ideal 
editor would be multi-modal, allowing visualization in all the 
application-specific domains a document traverses.

XML is also used as the syntax for several programming languages, most 
notably XSLT. A programming language requires programming-specific 
features, such as debugging, testing, dynamic visualization.

Last but not least, there are those who want to visualize a document 
primarily as pure hierarchical structure. These people seem to me to be 
in the "outline editor" tradition and seem to feel most strongly about 
validity-driven editing.

These four editing modes, textual, representational, behavioral and 
hierarchical, all seem to me to be intrinsic to XML, which is at once 
text, a syntax for application-specific languages, some of which are 
programming languages, and a hierarchical specification. If there were, 
or could be, one magical editor that brought all these together (with no 
overhead, for all application domains of interest) then probably 
everyone would use that, because it is obvious that these modes are 
complementary. Sometimes one would use one mode, sometimes another, 
whatever got today's job done most efficiently. But of course no such 
editor is likely to appear, even setting aside the impossibilities of 
providing visualization for all application domains or magically 
delivering extra features at no cost. In the real world, we will be 
served by editors that either try to do one mode in one domain very well 
or try to do several modes/domains simultaneously (employing plugins, 
dependency injection, etc.) but perhaps inevitably are not quite as good 
as the best-in-class restricted-mode/domain editors.

That is really the end of my comment, except for this: It seems very 
strange that in this entire thread about XML editors no one has 
mentioned the elephant in the living room.

Bob Foster


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

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