Category: xml

Larry Masinter believes there is a risk in making ‘the “meaning” of [a] language depend on operational behavior‘.

In discussions like this there should be a sharp distinction between natural and computer languages. Larry says meaning ‘depends on what the speaker intends and how the listener will interpret the utterance’ – that’s a valid viewpoint for natural languages, but for markup (html, xml etc.) or programming languages it’s really stretching definitions. There is no speaker, and no direct intentions – unless software has intentions. For markup document instances, there are usually three indirect intentions: those of the language designer, the software builder and the end-user producing the instance. I’m not sure an approach based on intentions is workable for computer languages at all – whose intention does the document reflect? How do we know the intentions of end-user, software builder and language designer do not conflict? How do we know their intentions at all?

Besides, semantics in this way can be described in prose or first order logic. I don’t think first order logic is appropriate for most language design (it’s not human readable, only logician-readable), and prose may be fine but is often inexact. I spoke at length at Balisage 2008 on this issue, and discussed it with David Orchard and others, and I believe an operational approach is often appropriate for computer languages. Why? It certainly is problematic for natural language semantics. There may be an utterance, and a meaning, without any behavior – I can say ‘North Korea tested an A-bomb’, and that has a meaning, even if no-one exhibits any behavior whatsoever after my words. For computer languages, it’s different. It’s possible to describe operational behavior as testable conditions – if I send a system test message A, it should do X. And that makes operational semantics a nearly perfect fit for computer languages – the semantics can be tested with a test suite. That’s enough. No need for real-time behavior after receiving each message.

Larry writes: ‘…standards organizations are in the business of defining languages … and not in … telling organizations and participants … how they are supposed to behave’. That’s far too lenient. If I render text marked <b> as italic, and <i> as bold, I’m not following your spec. Period. If I implement a language specification, and claim conformance, I’m not free to do as I choose. This is even more true in other contexts – business, healthcare, insurance. There organizations exchanging documents sign contracts, and are legally bound to do certain things upon receiving documents – paying after ordering, for instance. Larry’s free-for-all approach to language definitions does not apply to the real world. It’s only true that behavior should not be constrained any further than necessary – but without behavioral consequences, document exchange is meaningless indeed.