Hi, Jim.

>Your advices below are all very sensible, but it would be interesting to know if these 'rules of thumb' (and others that I have seen stated along similar lines) are "official" in any way or purely based on experience.

My word can't be taken as official in any way. I don't belong to the W3C or any other consortium, nor any of the companies driving XML (namely Microsoft, IBM, etc). Beside that, my advice is based on experience, but also in a certain understanding of the XML development and purpose.

>If "official" then I'd say that XML's future is limited or, at the very least, these limitations are in need of becoming widely aware.
>If based solely on experience, then I guess that you are communicating the 'present state of affairs' and their implications to developers.

Well, take it as the advice from someone who invested some time studying this stuff. My work involved more bieng up-to-date and "understanding" tecnologies than actually coding.

Basically, what I tried to say is that XML is not intended to be a silver bullet for everything. The important thing about XML is standarization, parseability, hierarchical capabilities, tyiping abilities, and plain-tag-based-format. This last item make it ideal to transaport data over HTTP, and thus, to exchange information over the web.

But this doesn't imply that it have to be prepared to exchange HUGE datasets. Indeed, it is related with the opposite. The web is prepared to work with small sets of data out of BIG repositories (like anyone using Google knows).

If you are thinking about building an application to be run internally over a high bandwith network and needing a really fast performance, then you don't need XML to pass data around, and you have lots of better approaches.

As usual, the old "the best tool for every..." song applies here.

Hope this clarifies my point.

Best regards,