In the article it says: "XML essentially is a programming language..." Well, it's a markup language used for content presentation in a compact form (not so compact as in s-expressions, though), so it's not a programming language. XSLT is.
They're reading a brief news story, not an in depth analysis. Presumably they're smart enough to go elsewhere if they want to learn more. I'm not saying to write something incorrect, I'm saying the trick is to write something that's both correct, and comprehensible to the average person.
Well, to the Von Neumann architecture, data and instructions are all the same. Just a matter of where the Program Counter points to.
Also both XML and XSLT are interpreted. Meaning a real program reads the source and manipulates the system accordingly. I really have no problem treating the two as equivalent.
Depends on your definition of "programming language" as well as "markup language". One could argue that XML isn't anything but a specification of a syntax (Similar to s-expressions). But then "markup language" is an imprecise term (regardless of what the abbreviation stands for). It's a "syntax".
So, if by "markup language" you mean "syntax", then I'll give that they are different categories, but then I would also argue that you're using the wrong word.
There are languages that fit both (such as Tex, and consequently, Latex), but this does not preclude us from drawing a distinction between the two in clear-cut cases (such as HTML versus C).
> ... drawing a distinction between the two in clear-cut cases (such as HTML versus C).
If anything, declarative languages (or markup languages if you prefer) are a sub-category of programming languages. Imperative languages are another sub-category.
To me, a "programming language" is a language that allows me to express computations. Markup don't need any concept of computation, so I don't consider them programming languages.
XML isn't a programming language in the same way ASCII isn't a programming language -- in the same way CSV isn't a programming language. Not because of turing completeness, but because they are a completely different thing.
The DTD is just a regular expression, and your document as a string to match. The validator is the interpreter that gives you a yes/no answer for any problem you can represent in those terms.
Actually... hmm. If you look closely at the entity replacement rules, the conditional inclusion entities, and the ability to include external dtd references, you may well be able to get full turing completeness.
