Re: XML-based text editor: a proposal
>> http://www.kirsanov.com/te/te.html > When I read your paper, I have a flashback. You try bulding > on piped transfromations ( "two transforms working together" ), > you try to use XSLT when ( I'm serious ) CSS model would make > *much*better*design* ('properties inheritance' is kinda general > mechanizm, which is in my oppinion underestimated) In fact, in application to my model, there are two aspects to inheritance of properties (or aspects as they're called in the paper): 1 Inheritance between views. This is implemented in (de)constructors that by default copy all aspects they are not programmed to handle from the source view to the target view. 2 Inheritance within non-flat views. This is defined by the nature of a particular aspect. Some possibilities are: 2a child tree element inherits the aspect of its parent element - for example, the visibility aspect; 2b child tree element obtains the aspect value from its parent but changes it - for example, the cursor position; 2c child tree element combines aspect values from its parents - for example, color, font, and other CSS-like properties. > I'd suggest the following design approach: > > 1. Think about the document as if it is a tree that you can > access by ( not existant ) XPath--. Done, except that it's not one tree but a tree (hierarchy) of trees (views). What exactly do you mean by XPath--? Are you proposing to cut something off and if so, what? > 2. Your XPath has to be bi-directional, you should be able > not only to get some propreties, but to set them as well. Probably that could make sense. (Isn't this XPath called "XQuery with updates" nowadays?) > 3. Properties should be cascaded ( CSS ). Yes for some of them, see above. > 4. In fact, when saying 'property' I'm talking not only > about the properties presented in the document, but also > about the properties, 'attached' to the tree by the editor itself. Exactly. Aspects, as described in the paper, can hold both visible properties of text such as color and some meta-properties that are only used by (de)constructors and transforms but do not affect the display engine at all. Users are free to add their own aspects if necessary. > 5. Try to use XSLT-izms for processing of mixed context only, > because that's the best use for XSLT. Which accounts, I think, for a majority of cases. Most high-level views will have some untagged data. This is to be expected, as the editing environment is naturally document-oriented, not data-oriented. > 6. Open the framework described above to plugins > that could be possibly written in *any* language. > ( Java [expletive deleted] for text processing. Perl or Python > would do much better job ). I agree wholeheartedly. The more the merrier :) Of course in the ideal world, one can script his/her text editor in the language which is best for him/her. I used XSLT in the paper because this is the only language in which I know how to access XML trees and because I use this language daily. However, the language used in transforms and (de)constructors is orthogonal to the main idea of the paper, that is: the hierarchy of automatically updated views, aspects propagating across views, and transforms working on the views' trees. > When saying 'supporting a big number of > XSLT transformations I'm not talking about supporting > 100 'hello-world' XSLT transformations. I don't think emacs > modules are as simple as 'hello-world' and if it was > hard for LISP it would be still hard for XSLT, > right? As I wrote in the paper, pure XSLT is sure to be insufficient, and it will have to be extended for the purposes of TE anyway. Maybe this language has even more serious drawbacks that are not yet obvious to me as an XSLT user. However, I was taught that proper data structures are fundamental while proper code is secondary. Emacs' Lisp get at times really ugly because it has to parse and reparse again the flat document and store the results in ad-hoc structures that do not live long enough to be useful. So the main point of my paper is that, with a rich hierarchy of well defined persistent views, the task of writing applications for the editor becomes much much easier, no matter what language you use. -- Thanks, Dmitry Kirsanov http://www.kirsanov.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