Web developers will embrace XML when they embrace
the whole package.
Web developers do not object to XML as means
of formatting data, i.e., part (a) of the package.
Web developers do object to the verbose, arcane
validation languages (b) and the verbose, arcane XML
programming language (c). Specifically, Web developers
object to XML Schema and XSLT.
Web developers would embrace the package if XML came
bundled with a concise, common validation language and
a concise, common programming language -- the validation
language and programming language are non-XML syntax.
I would contend that RNC and XQuery may very well be those languages. I've managed to get Java developers up to speed on XQuery within a few days, and while there are some idiosyncrasies associated with XQuery, the language is FAR more intuitive to a Java developer than XSLT is. Similarly, RNC is a compact mechanism for encoding a schema. The reason that there isn't a big uptake in them at this point is partially an education issue - most developers don't understand what XQuery is until they actually sit down and work with it - and partially implementation - there is currently one XQuery implementation in the browser (XQIB, which is cool, but still buggy and not terribly well documented) and XQuery is not yet a part of the standard Java core library, though there are a number of ways of utilizing from third party libraries such as Saxon or DataDirect.
Similarly, RNC has been around for a while, but you have to go out of your way to be able to utilize it. Personally, I'd rather be designing with RNC than XSD, but XSD still has the momentum.
Here's what would make at least some difference - someone (perhaps I'll do it at some point) write an XQuery processor in JavaScript that can take an XQuery string or document in exactly the same way that you can use the XSLTProcessor today in JavaScript:
var xml = someProcessToGetAnXMLTreeOrNode();
var xq = new XQueryProcessor();
var xqBind = xq.bindString("for $item in //foo/bar order by bar ascending return <li>{bar/string(.)}</li>");
var data = "xq.query(xqBind,xml);
for (item in data){print(item);}
or
var xqBind = xq.bindScript("myXQuery.xq")
...
Once you have something like this (JSR 225 - XQJ provides the equivalent for Java) then you basically have a mechanism that lets you work with XML without needing to create a complex XML infrastructure. Get this into a major AJAX library such as jQuery and XML would see a dramatic jump in usage.
Kurt Cagle
XML Architect
Lockheed / US National Archives ERA Project
