[
Lists Home |
Date Index |
Thread Index
]
>> 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 sucks 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
|
