Sean Russell wrote: > > 1) If you don't, you'll get limited acceptance. You may draw TeX users, or > the XML nuts like myself... but you won't get anybody converting from Word. > Believe me, I tried at my last contract to get people to use XML as a > standard document format so that we could manage critical documents > centrally. It was impossible to get buy-in, because of the relative > difficulty of the existing XML document-oriented editors (Morphon, at the > time :-/). XXE is loads better, but knowing that group of people, I don't > think it is quite to the comfort level where they'd accept it as a substitute > > Notice that I do believe that, even if it isn't a "Word" experience, they'll > be willing to cross over. Many professional end users, I've found, aren't > sticklers for having a Word clone if you can argue the benefits of a better > document format, such as XML docbook -- as long as the tool is sufficiently > easy to use. If it is painful to use the tool, only masochists will use the > tool. Again, these people don't care about the fact that the document is > docbook, except peripherally -- they just want to be productive and write > documents. > > Another assumption I'm making for this point is that you even care about > getting average users to use XXE. You may not, which is your prerogative, > and in which case, this point is moot.
Our strategy for making XXE easy to use for the average user is to let ``power users'' customize it for specific XML applications, not to add more generic commands or to make generic commands more powerful. Customization means specifying macro-commands, adding custom key and/or mouse bindings, popup menus, menu bar menu, toolbar icons (in a XML-application specific XXE configuration file such as config/xhtml/xhtml.xxe). We even want to be able to replace, the standard view of an element (text, icon, border, color) by a custom one (Java Component implementing simple interfaces) if this is critical to the productivity of the user. This is beyond customization: this is specialization. Example 1: Show a temperature attribute as an embedded thermometer. Let the user drag the quick silver level to change the value of the attribute. Example 2: Embed a button in the document view which inserts (after the element for which it is generated content) a predefined element template. This said, may be your idea is a great one. We need to be rejected by average users a certain number of times (with the symptoms you describe) before trying to implement it. > 2) The world has more than enough tree-oriented XML editors. XXE is a > document-oriented editor. I believe that this difference in perspective > makes all the difference. The assumption is that people are using XXE as a > word processor. The document structure itself is incidental. If you could > find a way to completely hide the document structure and maintain its > validity, wouldn't this be valuable? In the end, for most documents authored > with XXE, the use is going to be in some human-readable visual display. > > > > However, adding just the legal ancestors to the list > > > I think is a reasonable compromise because the number of extra element > > > choices will always be relatively small > > > > It depends on the DTD/XML Schema. > > I'm only talking about adding the direct ancestors which can legally follow in > the document. How deep are the elements being stacked? 10? 100? I'd be > surprised if you could show me a /document/ oriented XML document that has a > child that is more than 10 elements deep ... IE, count( ancestor-or-self::* ) > > 10. I'd be /really/ surprised if you could show that this is common :-) DocBook example: the caret is inside an emphasis element which is inside a para element, which is inside in a section, which is inside... (but let's stop here). After an emphasis, you can insert (i.e. elements that would not make your document invalid): command link interface replaceable guiicon quote exceptionname keycombo revhistory errorcode structname superscript envar sgmltag cmdsynopsis guimenuitem symbol fieldsynopsis anchor constructorsynopsis emphasis structfield authorinitials keycap action menuchoice keysym citerefentry computeroutput parameter productnumber xref errorname guilabel methodsynopsis glossterm author foreignphrase email interfacename ooexception varname acronym optional ulink indexterm constant type option remark errortype application guibutton inlinemediaobject guimenu citetitle medialabel wordasword prompt classsynopsis trademark footnoteref mousebutton userinput function methodname inlinegraphic footnote keycode ooclass synopsis returnvalue subscript guisubmenu filename hardware funcsynopsis destructorsynopsis productname inlineequation markup phrase systemitem literal modespec corpauthor database abbrev othercredit citation oointerface classname beginpage firstterm token property olink After the para, you can insert: screenshot programlisting simpara formalpara blockquote procedure figure cmdsynopsis calloutlist caution warning equation example tip fieldsynopsis sidebar classsynopsis note constructorsynopsis address informalexample qandaset anchor mediaobjectco abstract literallayout synopsis simplelist mediaobject graphicco segmentedlist table destructorsynopsis funcsynopsis methodsynopsis informalfigure para itemizedlist bridgehead sect2 msgset informaltable authorblurb screen graphic screenco orderedlist glosslist important indexterm informalequation remark variablelist highlights programlistingco epigraph beginpage Yes. DocBook is a monster. Here we need a DocBook specific menu which implements your idea but limiting it, not only to valid elements, but also to commonly used elements. Also note that with an XML Schema, you can have different element types having the same element name. Example: the caret is inside a xyz:span, which is inside an xyz:para, which is inside a xyz:section. (xyz denotes the prefix of the target namespace of the schema). Before the xyz:span (because it is first child of xyz:para), you can insert xyz:info which is meta info about the xyz:para. Before the xyz:para (because it is first child of xyz:section), you can also insert xyz:info which is *totally different* meta-info about the xyz:section. > Now, it may be significantly time-consuming to determine which ancestors can > be legally inserted somewhere in the document -- I don't know how you're > doing validation internally. However, the number of elements added to the > list will remain small. > > A better argument against my request is whether the ease-of-use benefit of > adding this outweighs the confusion it might produce. I don't know. I > believe that it would be more useful than confusing, but I don't know. Yes. We generally experimented on ourselves (here at XMLmind) new features of XXE by writing at least a few dozen pages, with a couple of DTDs/XML Schema, before deciding if they were worth keeping or not. We also used pretty slow PCs for these experiments. > > But in the short term, we don't have the resources to experiment this > > idea using a native implementation. Sorry. > > I can understand. 'Course, you could make the source-code available and I > could take a look at it myself ;-) The Professional Edition (~$200) includes full source code. XXE is not intended to be an opaque product.
