Lists Home |
Date Index |
> We have more than one tool in our collective kitbag, and they all have
Michael, of course they have and of course they do.
But that's part of growing a community: to build common knowledge about
what are the tools at our disposal, to learn what each does and can do
and learn what to use under which conditions.
My advise to this community is very simple:
Concerning XML processing, do use declarative processing languages like
XSLT or XQuery as much as possible.
And if you hit problems with those technologies (as I am sure you do)
bring feedback to this community about how would you think we should
improve them, and we will improve them.
In today's context, it is much more important to optimize software
productivity, code correctness, robustness and possibility of evolution
then it is
to optimize for performance.
There are very many reasons for that, among which:
(1) Performance ALWAYS comes when a technology achieves a certain
mass of users.
(2) Productivity, correctness, robustness and possibility of evolution
after the fact (i.e. after the software is written): it's either there,
or or it's not there.
If you need them (and we DO need them), the best one can do later is to
software, or to add another abstraction layer in top, which we all know
bad consequences has in long run, both in terms of the complexity of
architecture, and also performance.
XSLT/XQuery allow for better productivity, correctness, robustness and
evolution then hand coded solutions do.
Hence, it is better for us as a community to work on building a
critical mass of XSLT/XQuery
users, then to spend our energy on building the optimal low level
technique. The first strategy will pay off in the long run, the second
That's my advise, people can take it or leave it.
P.S. The horse was already dead and buried, but I received a lot of
private email, so I
thought it is simpler to answer collectively.