[
Lists Home |
Date Index |
Thread Index
]
From: "Dmitry Kirsanov" <dmitry@kirsanov.com>
> > 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.
|
