On Arjun's comments.
May I argue that keeping data content untyped strings (i.e. you need a XMP Schema or casting to determine its type) but allowing limited basic typing of attribute values in no way compromises any theory of what tagging should be used for what purposes?
The only thing it does take advantage of the low hanging fruit that is particularly applicable to classic SGML documents where your text, in data content, is tagged with elements and annotated by simple attributes. So that, for example your document (using a DTD if you like, or not) can be ingested from text to DOM so that, say, numbers, booleans, dates and names that are attribute values are automatically made typed values (so that a programming language or script knows what to do with them without casting or conversion, and so that parsing will throw up any lexical errors - eg for dates.)
And, in the data-oriented cases Arjun raised (always thioughtful, as ever), why won't it cause "tag abuse", my answer is that any new projects for this use-case will have switched to JSON, in large part because you get this inline typing and therefore autonatic databinding. We don't really need to worry about tag abuse for a use-case that does not exist anymore, do we?
(Now, I am not saying that for data JSON is always the best, nor that XML doesn't have other features that may make it best to provide feeds in both JSON and XML, nor that if you currently have a good XML infrastructure you should rip it up and not take advantage of it.)
I like this syntax idea (unquoted attribute values have defined lexical types) not because it would compete with JSON more, but because it would take a clue from JSON and make traditional SGML-style publishing systems easier: particularly in internal pipelines which are inevitable done with no formal DTD or schema (i.e. normalized data.)
Cheers
Rick
Just for clarity, this idea is not the one from the
schematron.com site, which is just suggesting that XML's performance and complexity issues have now come to the point where they fight against current technology (CPU design in particular, but JSON archictures also). And that rather than arbitrarily saying "How small can we make XML?" a better approach is "How much can we keep in XML, yet overcome the blockages to parallel implementations that has stumped all academic studies of the possibilities? (Note in regard to pipelines, my post on XSLT "Pipelines considered harmful" on Schematron.com, if you are interested.)
