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