size of XQuery developer community

[Martin Probst]

> With all due respect, one major reason why XML/XQuery/XSLT isn't as popular
> as many other programming languages has less to do with ignorance of it's
> capabilities and more to do with it's 1) lack of performance, 2) overall
> information bloat, and 3) unintuitive language constructs.

Regarding performance, we're certainly not at the performance levels
of relational databases, but I think for many cases we're "good
enough" (even though faster is always better/cheaper).

About language constructs: yes, there are some things which could have
been better in my opinion, but probably everyone has its own opinion
about that. My pet peeves are xmlns="" declarations in literals that
change namespace scope, "return" that does not return, and the general
wordiness of the language. For my taste in languages, XQuery has much
too much syntax. This is one of the reasons why I wouldn't recommend
it as a general purpose programming language.

> Sure disk space is cheap and bandwidth is getting more *broad* every day,
> and "many elegant designs have been sacrificed for the sake of
> performance...yada...yada...yada...", but at the end of the day, the same
> data that can be represented in XML can be represented a lot more concise in
> other platform-independent formats.

If you look at XML databases, you might find that they do not go
around and store angle brackets. In xDB's case, what ends up on the
hard drive is usually quite a bit smaller than the original XML (you
know, the one with angle brackets). So if you need to store and
process large amounts of XML, just pick the right tools - this is not
an inherent problem with XML.

What I find much more problematic is the amount of cruft XML by now
has, and which greatly complicates anything built on it. We have
processing instructions, DTDs, notations, entity references, internal
DTD subsets, document fragments, and so on. All of these need to be
supported by XML processors at least to some degree, and they greatly
increase the conceptual surface of the language. I'd be willing to bet
that you can find some XML construct that behaves at least
unexpectedly in any larger XML processing tool, just because it's
getting increasingly difficult to cover all cases. This is where
simplified schemes such as JSON shine - they have a much smaller
"surface".

Martin