[
Lists Home |
Date Index |
Thread Index
]
> > 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.
>
> I'd suggect calling them not Aspects, but 'Dimensions'.
Terminology is secondary, but that's a bit pretentious for a term, to my
taste :) Also, one of the points in the paper is that the aspects taken
collectively are a "dimension", one which is perpendicular to the
dimension of the views.
> > Which accounts, I think, for a majority of cases.
>
> I'm not so sure. The 'text itself' looks like the only dimension,
> where mixed content is important.
Not quite. For example, apart from Python, most programming languages
don't pay much attention to whitespace; this means that in views
developed for such languages, whitespace will likely be left untagged,
and only keywords etc. will be incapsulated into elements. This will
result in mixed content.
> I think you alreary started to realize that one can take XPath
> out of XSLT and then use some general-purpose
> language.
Yes. Although I still hold that for most everyday tasks, XSLT is very
convenient and intuitive, so it must be provided as one of the supported
languages. But being language-neutral is a good thing because it can
potentially attract more developers to the project (if it ever takes
off).
> For example, XPathScript (See AxKit ) which is
> Perl + XPath is more handy for system-level
> tasks, than XSLT ( and to scale, your editor
> *have* to support system-level tasks, like it
> is in emacs )
It seems likely that really performance-critical system tasks, such as
lower-level (de)constructors to and from the chars view and other flat
views, will not need any fancy XPath at all, but only some rather
primitive node traversal. Therefore for such tasks, any compiled
language that can work with DOM trees will be a good choice.
> So next step is : why restrict it to Perl only?
>
> Allow binding with any language, trought the
> binding layer, silimiar to Chunks' CPath
> ( http://www.pault.com/pault/pxml/nxml.html )
> ( I'm not proposing exactly that model.
> Wait for version 2. )
For low-level access (without XPath), probably DOM can be such a unified
interface. For more useful higher-level transforms that need XPath, we
need a different interface that allows any language to perform XPath
queries and do other things taht XSLT usually does.
> > 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.
>
> Sure thing. But why bother extending that poor XSLT animal,
> which get's constantly extendend for years in different ways
> by almost any XSL developer ... ???
On the other hand, if people continue improving it, this means there was
something really attractive in it to start with...
> > 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.
>
> Agree! The real problem here is to design such a "rich hierarchy of well
> defined persistent views" ( and abilities to add user-defined Dimensions )
This is the point. The paper is a first attempt to outline such an
architecture, and any suggestions in this regard are much appreciated.
However, I think it can really start developing only after there is a
working prototype.
Thanks Paul for your comments, I'm going to update the paper now to
reflect the new insights I gained in this discussion. As for XSL FO and
TeX, that topic is very interesting but may be off-topic here, so I will
write you separately on that subject.
--
Thanks,
Dmitry Kirsanov
http://www.kirsanov.com
|
