The XML FAQ

C and C++ (and other languages like FORTRAN, or Pascal, or Visual Basic, or Java or hundreds more) are procedural programming languages with which you specify calculations, actions, and decisions to be carried out in order:

mod curconfig[if left(date,6) = "01-Apr", 
    t.put "April Fool!", 
    f.put days('31102011','DDMMYYYY') -
          days(sdate,'DDMMYYYY')
    " more shopping days to Samhain"];
	  

XML is a markup specification language with which you can design ways of describing information (text or data), usually for storage, transmission, or processing by a program. It’s ‘program-agnostic’ in that it says nothing about what you should do with the data or how you should process it (although your choice of element names may hint at what they are for):

<part num="DA42" models="LS AR DF HG KJ" update="2001-11-22">
  <name>Camshaft end bearing retention circlip</name>
  <image drawing="RR98-dh37" type="SVG" x="476" y="226"/>
  <maker xml:id="RQ778">Ringtown Fasteners Ltd</maker>
  <notes>An <tool xml:id="GH25"/>angle-nosed insertion tool</tool> is 
    required for the removal and replacement of this part.</notes>
</part>
	  

On its own, an XML file (including HTML) doesn't do anything. It's a data format which just sits there until you run a program which does something with it. See also the question about how to run or execute XML files.

The water is muddied by the fact that the most popular transformation processing languages (XSLT3 and XSL-FO) are actually written in XML syntax, because they are declarative languages, not procedural (see on this page for the distinction). In these two cases you could be said to be ‘executing’ an XML file, although strictly speaking they are scripts, as they are not compiled but interpreted by running a processing application like Saxon, which interprets the templates specified in the files into executable Java bytecode to process XML documents. In this sense, you could compare them with other programming languages, but you would be comparing the language facilities, not the XML syntax in which they are written.

Ken Holman writes:

Procedural and declarative languages

(Asked to counsel which implementation language to use in a new project, and when to advocate for declarative XSLT over Java and other traditional imperative (procedural) programming languages, G. Ken Holman offered his opinion:)

I worry any head-to-head comparison with an imperative language programmer regarding any given single task will degenerate into complaints about verbosity and ‘too many angle brackets’.

• Imperative languages are designed to dictate the outputs (pull model).

• Declarative languages are designed to react to the inputs (push model).

XSLT outshines imperative approaches when you leverage import precedence with the ability to declaratively override behaviours with onion-skin outer layers that supplement or inhibit inner-layer behaviours.

XSLT was designed for publishing where these layers can interact and provide fine-grained control of a read-only core with selective outer solution-specific details. In publishing, the author of the XML is in control of the output, not the programmer. The publishing task has to react to the arrival of content in order to produce the output. Outer-layer behaviours can intercept the handling of arrived content and behave differently as necessary to override default or built-in behaviours.

Consider as an example the publishing services at https://RealtaOnline.com where at the bottom of the home page you can see two dozen standards organizations each getting their own customized national presentation of standardized content. There is a single core set of declarative behaviours supporting NISO-STS XML presentation. Each client is supported with their dedicated onion skin. When core behaviour is enhanced, every client benefits. When any client wants specialization, other clients are not affected.

Onboarding a new client takes hours to get their own cover sheets, headers, footers, fonts, geometry, etc.

This is the benefit of the declarative approach: the core need not know how it is being leveraged. There is, however, an obligation for the core to be written in the way to be specialized.

And this isn't reserved for publishing … in your real-world situation it is the essence of leveraging the push model of input processing and which component (input or program) is driving the content of the output that should guide your choice of implementation.

In your new project, if you have the need to leverage common behaviours for multiple differentiated outputs, your use of XSLT should be readily justified.

If, however, you have a single task that is single purpose … well, then I suppose the declarative style comes down to personal preference, familiarity, and plans for maintenance.

William Hammond writes:

(in article <i7ll1362ib.fsf@hilbert.math.albany.edu>)

SGML is a category of ‘document types’, with a configurable shared syntax, most of which (like classic HTML) cannot be compiled to produce executable programs. XML is a subcategory of SGML with syntactic restrictions. For example, with XML the vocabulary of a document type is always case sensitive, while with SGML it may be either case sensitive or case insensitive. So, for example, classic HTML is an SGML document type, and XHTML+MathML is an XML document type.

While some document types correspond to document markup languages, other document types (like a CTAN catalog entry) are just for structured data[...]

I doubt seriously, however, that a computer language like C is in any reasonable sense equivalent to an SGML document type.