Lists Home |
Date Index |
> > http://www.kirsanov.com/te/te.html
> I guess the reason to do this is much like the reason to write most any
> program in most any programming language. For a program that has been 'done
> before' such as a text editor, you would want to see either some sort of
> performance increase, some new functionality not achieved, or perhaps a
> greatly improved portability.
The main advantage of the XML-based editor architecture that I see at
this point is the ease of implementing common editing applications
(compared to conventional editors whose scripting language has to deal
with a single flat view of the document). It seems likely that if the
idea proves workable, new functionality motivated by the new
architecture will emerge as well.
> The best way to evaluate this is to 'go for it' and write the code. It would
> be fairly interesting to see how difficult this would be in XSLT. The result
> would probably be categorized into either a) stupid XSLT hacks (been
> there,done that :-)) or b) "WOW!"
I'm starting to realize that XSLT is not a critical component of the
system. The real core is XML and XPath, and as an application developer
(or simply a user who needs to hack a macro or two), you can use any
language you prefer to navigate and transform XML trees using XPath. And
for performance-critical parts of the system, such as view constructors,
even XPath may prove too heavy; these can be implemented as modules
written in some compiled language, working on DOM trees of the views.
However, for the end user, XSLT is a great choice which natively works
with XPath and allows to quickly and intuitively write most simple
transforms and high-level constructors.
> Now if you can convince _someone else_ to write it,
I'm not a programmer, unfortunately, which is why I'm soliciting
comments from developers. If someone volunteers to create a prototype,
that would be really great. If it works, we could then start an open
source project to turn the idea into a real product.