I really should know better than to get involved in this discussion as I know I will only demonstrate my ignorance. However, who knows what tomorrow brings.

Everything can be done better the second time around, that is a fundamental truth I have decided.

Taking these issues in order, maybe I can ask a few questions?

Whitespace: surely if default whitespace normalisation is an issue, then that can be solved by CDATA sections (which are used extensively by GMail I just noticed)?

Namespaces: Without them XML wouldn't have a reason for being surely, I cannot understand this being considered a problem, other than perhaps browsers support them in different ways?

XSD: This is a big one, maybe time to have another W3C recommendation alongside XSD?

DOM API: For the norms of the times probably a good effort. jQuery etc. has made that API somewhat redundant in the browser, so maybe just recognise jQuery as a DOM DSL (but adding XPath support would be cool). You have to admit that D3.js is quite marvelous (which uses the jQuery approach), now that we finally have SVG support cross browser.

But my main issue is this: If things can be improved then do so, if not move on and not dwell on what might have been. XML support in browsers is now very poor, can this be fixed, probably not with the current browser options who are focused on the growing 'application-platform' market, I guess in response to what is happening in the mobile arena with 'sexy' native apps.

Instead, I really do wonder if there is not a whole diffferent set of users that would benefit from an XML Technologies browser platform (that supports natively all the current versions W3C XML recommendations ), as much for processing data/information in a client-centric way, rather than in the thin-client manner that most web application development is being done at present. Kind of a super browser in my mind, the science community is maybe likely to take notice of this option (and EXI be a thing of value as well). RDF has been taken up by some science communities I understand.

> [Personally, I wish people would stop fueling this notion of XML being too complex.]
>

One thing we have certainly learnt is that XML could have been even simpler without throwing away anything useful.

We know there are some things like whitespace, and namespaces, and XSD, and DOM APIs, that cause a lot of trouble, and we know these could have been done much better.

We know that the poor layering of the specs is the root cause of some of these complications, notably the fuzzy boundary between the "physical" and "logical" levels of XML, and the absence of a definitive data model.
Michael Kay
Saxonica