[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML-appropriate editing data structures
Bryce K. Nielsen wrote: > ----- Original Message ----- > From: "Henrik Martensson" <henrik.martensson@b...> >>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 their > own preferences on how they prefer editing their documents, just like HTML > 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 http://xmlbuddy.com/
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|