Sean Russell wrote: > > I wasn't clear enough. *Only* legal ancestors. Ancestors. Not ancestors and > their siblings... just ancestors. Ancestor's siblings would certainly > confuse the situation significantly, but *only* the direct ancestors of the > current element would be beneficial. Even in your example, there are... > what... 4 ancestors? 5?
Sorry, I didn't understand that. You are right: there are always few legal ancestors. > I'm in /chapter/sect1/sect2/sect3/para. What am I *likely* to want to insert? > Either another para, or another sect3, sect2, or sect1. Seriously. The vast > majority of the time I'm inserting, I'm either wanting to insert a sibling of > para, or one of those 3 ancestors. Considering that para has a couple dozen > siblings, adding another 3 elements isn't going to significantly add to the > number of elements that the user can choose from. > > If I'm right, and it is the case that it is common to want to insert > ancestor-or-sibling/self, then adding ancestor's to the list is a benefit. > If I'm wrong, the users are no worse off than they were before :-) The DocBook configuration that will ship with V20final specifies 12 tool bar icons for commonly used actions (customization done without any programming). I hope this will improve the usability of XXE for the average user. If if it is not the case, we'll try to find something else such as your idea. > XML Schema is a hack, and a bad one, by a bunch of industry representitives > who thought they knew what they were doing. They were wrong. I'm sorry, but > XML Schema, basically, sucks. I was standing in the shower just the other > day thinking: "W3C XML Schema looks like it was designed by a committee." > Then I thought "Hey! It was!" It has all of the horrible design of DTD, and > all of the terrible verbosity and bloat of... well... the recent Java APIs. > Actually, the Java APIs aren't *that* bad, but lord, they aren't getting any > better. The 2D API is an exception. But I digress. XML Schema is not an inspired spec. It is quite complicated for a result which is not very powerful. But it is there now. It is a standard. It solves problems DTDs can't solve. And for these reasons, we think it will be used. > The obvious solution is to just choose the most recent sibling or ancestor in > the possible solutions. If there is a sibling of name X, and X also occurs > in the list of ancestors, choose the sibling... it is "closer". As long as > your choice rules are clear, no problem... and, again, the users are no worse > off than they were before, because choosing ancestors wasn't even an option. OK. > > The Professional Edition (~$200) includes full source code. XXE is not > > intended to be an opaque product. > > Hm. If I may be able to convince my client we need this, and that we need the > source. I hope the "personal" edition is less than that. :-) I'll buy it > anyway, of course. The KWord XML schema stinks, and OpenOffice is barely > better... and neither supports arbitrary schemas. Yet. I was not trying to convince you to buy the Professional Edition. I just wanted to say that source code can be bought at a very reasonable price (because, in our opinion, it is the ultimate documentation of the product). Standard Edition, not only the beta but also the final release, is free.
