-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Je Mon September 9 2002 09:56, Hussein Shafie skribis: > 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.
This is a good strategy. I like the possibilities you described -- very powerful. If your API is open, and clean, I'm sure you'll get a lot of contributions for plugins. Have you looked at jEdit? Their plugin manager is, IMHO, one of the best software management systems in existance today. > 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. I'm afraid you'll never hear from the rejections. I only rarely write software authors to tell them that "I'm not using them because of XXX", and I /never/ tell commercial software providers. > > I'm only talking about adding the direct ancestors which can legally > > follow in the document. How deep are the elements being stacked? 10? ... > > 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): 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? 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 :-) > 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. That's what I meant when I said "hobbled by DTD". > Also note that with an XML Schema, you can have different element types > having the same element name. 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. 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. > 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. - --- SER -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9fUrhP0KxygnleI8RAn1qAJ9zWNY2kN5wzA6JsPMcWjJP+0T05wCePo9e sZAxpGqKF8P89VmR00l//KQ= =SeKr -----END PGP SIGNATURE-----
