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

Re: Streaming XML (WAS: More on taming SAX (was Re: [xm

• To: "'XML Developers List'" <xml-dev@l...>
• Subject: Re: Streaming XML (WAS: More on taming SAX (was Re: ANN: Amara XML Toolkit 0.9.0))
• From: Daniela Florescu <dflorescu@m...>
• Date: Wed, 29 Dec 2004 09:00:57 -0800
• In-reply-to: <E1CjZMi-00008c-00@u...>
• References: <E1CjZMi-00008c-00@u...>

> We have more than one tool in our collective kitbag, and they all have 
> a
> place.

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 
for us,
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) 
please
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 
design for
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 
critical
mass of users.

(2) Productivity, correctness, robustness and possibility of evolution 
DON'T come
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 
rewrite the
software, or to add another abstraction layer in top, which we all know 
how many
bad consequences has in long run, both in terms of the complexity of 
the overall
architecture, and also performance.

XSLT/XQuery allow for better productivity, correctness, robustness and 
possibility of
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 
buffer management
technique. The first strategy will pay off in the long run, the second 
no.

That's my advise, people can take it or leave it.

Best regards,
Dana

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.

• References:
  • RE: Streaming XML (WAS: More on taming SAX (was Re: ANN: Amara XML Toolkit 0.9.0))
    • From: "Michael Kay" <mike@s...>

• Prev by Date: Re: performant templating language for XML
• Next by Date: RE: performant templating language for XML
• Previous by thread: RE: Streaming XML (WAS: More on taming SAX (was Re: ANN: Amara XML Toolkit 0.9.0))
• Next by thread: Re: Streaming XML (WAS: More on taming SAX (was Re: ANN: Amara XML Toolkit 0.9.0))
• Index(es):
  • Date
  • Thread