[falcolas]

> XML is not a "data description language", it is a type system

XML means "eXtensible Markup Language" - so pretty much exactly a description of the data it contains. Granted, you can mark up a bit of data with a type, but you can mark it up with anything else as well.

I've even seen entire programming languages built upon XML.

[drostie]

I actually don't think that would be all bad if you in addition paired some parsers and serializers for other formats in your standard library.

That could actually be a really fun language: "you can write this in Haskell-syntax, Python-syntax, or C-syntax, we don't care, just make sure that you enclose it in the corresponding

    <parse-as lang="c">
    // ...
    </parse-as>

and then `myprogram.c.x` will get compiled to `myprogram.x` which is a standard XML file, which you can then edit with `x-to-py myprogram.x >myprogram.py.x && vim myprogram.py.x` and have a field day of it."

Sort of like the PL equivalent of Lennon's Imagine.

[falcolas]

It was moderately more complicated that this, as it represented the actual program tree structure within XML. Imagine lisp with XML tags in place of parentheses.

[keithb-]

> XML means "eXtensible Markup Language" - so pretty much exactly a description of the data it contains.

This is the belief that Eric Browne argued against in 2003[1]. "exactly a description of the data" only works when a human looks at it, which is the same argument for JSON. These two things "describe" the same object:

<person><firstname>Eric</firstname></person> { "person" : { "firstname":"Eric" } }

But using Browne's argument, a parser might see these objects as:

<hshhd><uueus>Eric</uueus></hshhd> { "hshhd" : { "uueus":"Eric" } }

How does that description help the parser?

What I'm saying is that XML is system for defining types, subtypes, relationships, etc. and that this type system can be used by programs that are written to interact with document instances in a way that is not dissimilar from other statically-typed languages. In a sense, you're agreeing when you say that XML has been used for programming languages because, in that case, a document instance might contain blocks of programming statements not instructions for a machine. It must be parsed and compiled first which takes some knowledge of the type system, i.e. how to create AST's and transform them into instructions.

I'm also saying that the problem with XML comes from the inability to reason about type systems in a general way. I can give you my XSD but will you know what to do with my data? And if I give you the XSD, and I tell you what to do with the data, then won't we writing the same program? Wouldn't it be easier to just share a library?

[1] http://workflow.healthbase.info/monographs/XML_myths_Browne....

[falcolas]

That's because there is no implicit data structure to XML mapping by default. This is a good thing; it makes XML much more flexible.

Of course, that flexibility is what burdened us with SOAP, XBRL, and other monstrosities; but I blame the creators of SOAP, not XML. XML is the "C" of the data markup world (simple but flexible), whereas JSON is more akin to "Java" (heavily restricted in capability, resulting in workarounds to represent complex concepts).

    { "hshhd" : { "uueus":"Eric" } }

How would JSON be any better in this case?