[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XML-based text editor: a proposal


follow trought text
> > 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



PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.