Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: XML-based text editor: a proposal
 From: "Dmitry Kirsanov" <dmitry@k...> > > 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. That's not actually my point. http://www-106.ibm.com/developerworks/xml/library/x-domprl/index.html?open&l =136,t=grx,p=dwp <quote> The everything-is-a-node abstraction, while quite elegant, leads to awkward coding situations </quote> DOM + XPath + general purpose language is *not* DOM + natural purpose language. > 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. Plain DOM is almost useless. Too low-level. When saying 'DOM' I'm actually saying 'DOM + XPath' ( See Chunks ) I think that no matter what would you try to do in your design, earlier or later, you'l get the situation when you want some piece of code to update some part of your tree, not copying the entire tree with identity tranfromation, and then : BANG! XSLT? - nope. By design. XPath? - nope. By design. XQuery? - nope. Too heavy. DOM? - nope. Too low-level. The most reasonable solution from my point of view could be DOM + bi-directional XPath. Not existant. > > > 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... Yes, there was. The combination of push and pull processing + XPath. However, Larry Wall decided not to extend awk with hashes ( possible ) but instead he decided to re-build awk from scratch. And he was right, I think. On another hand, there were many clones of awk. So is awk 'good'? Of course, it is! Was awk obsolete when the first build of perl4 has appeared? I think - it was. My point is that XSLT is not 'bad'. I'd say that XSLT was *too good*, so that people started using it outside of it's domain. XSLT is now obsolete. Usual disclaimer - it is obsolete from my point of view, because I think that it's processing model is limited by it's original domain. > > 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. Could be. As I said - programming editor does not sound sexy to me, but there may be some emacs fans out there ... However, I doubt that many of them are reading the XML-dev list ... The rest will go off-list ;-) Rgds.Paul. 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
|||||||||
