[
Lists Home |
Date Index |
Thread Index
]
----- Original Message -----
From: "Dmitry Kirsanov" <dmitry@kirsanov.com>
> > 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?
Cut off some of axes and build on less messy
model, than currect Node. Unfortunately (or fortunately),
your paper already changed my view on this. The
basic idea is that XPath should be bi-directional at all costs.
We can discuss XPath-- offlist.
> > 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?)
I don't think so. Just look at their syntax.
> > 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.
I'd suggect calling them not Aspects, but 'Dimensions'.
Multi-Dimentional XML Text Editor, powered by recent
W3C standards, such as XSLT, XPath, CSS ... e t.c.
Two years ago one could make some money just writing
down the sentence, like that, with no product at all. He-he.
> > 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.
I'm not so sure. The 'text itself' looks like the only dimension,
where mixed content is important.
> > 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.
I think you alreary started to realize that one can take XPath
out of XSLT and then use some general-purpose
language.
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 )
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. )
> 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 ... ??? SAXON alone has tonns of
extremely handy extensions. Actually, I think that they
still have no saxon:evaluate in XSLT WD. Also:
<quote from xslt WD 2.0>
Language bindings were introduced allowing extension functions to be written
in Java or JavaScript. This feature has not been retained in this XSLT 2.0
working draft, because the Working Group decided that standardization of
language bindings was a matter best handled separately from the core XSLT
specification.
</quote>
If you're patient enough to wait for a couple more years ...
I'd say - just pass XML Atoms to/from normal languages with special
XPath binding and do whatever you want.
> 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.
Agree.
> 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 )
I'm telling you - what you're talking about is much more like
CSS on steroids + DOM + XPath , rather than XSLT.
What XSLT can do, it can do rendering into some formatting objects
( as it was 100 years ago. That was the task XSLT was designed for
and it is what it is good for )
And here comes the important thing.
Programmable editor is not interesting to me. I'm not emacs person,
I'm vi person. Also, I don't need syntax coloring and other things.
I feel very much comfortable wrtiting my code in black and white.
This means that I'l not invest plenty of my presonal time,
writing yet another Programmable editor. Of course it is just
my point of view, I know many emacs fans who would definately
disagree.
However. There is one 'editor' that I would be glad to
help with.
1. That 'editor' can be black and white, just plain text.
2. That 'editor' shold support rendering to formatting
objects of TeX + CSS
So instead of desiging a programmable editor, I suggest
you to think how can you possibly build XSL FO killer.
XSL FOs have been designed from scratch, like there
is no tomorrow and like there was no yesterday.
However, we know that TeX is a product of a genius
and we have plenty of TeX implemetations.
While the value of emacs is questionable
to me, the value of TeX is not. Throw out emacs -
I would not notice, because there is vi and sh.
Throw out TeX - and there is just nothing to repalce
it! Of course it is just my point of view, I know many
emacs fans who would definately disagree.
Whatever. The task I would like to participate in, is :
Re-design XSL FOs on top of :
existant TeX rendering engine
CSS
XSLT ( subset )
bi-directional XPath binding ( for plugins in other languages )
The task is slightly different from what you was
thinking to do, but :
1. I think that with your background you may design a
*reall* killer FOs.
2. There is a significant common part with the programmable
editor that you originally suggested.
3. First pre-release of TeX-based FOs would be immediately
used by big number of *very* professional people, who'l
start using it for some real-life rendering tasks.
4. I can hack TeX ( including source code ), I can do all the ground
development and help with design, but I don't want to make the
core design, because I belive that it should be done by some
person who has better experience in typesetting / printing domain,
than myself.
5. The world has no real need in yet another emacs, but
the world (still) has no nice solution for document printing,
and XSL FOs are ... not there ... yet ...
I think it would be better to give a new life to TeX, rather than
emacs.
Rgds.Paul.
|
