Senders and receivers

Conversations always have two sides - a sender and a receiver. They may be the same person or the same computer, and they may change roles on a regular basis, but sending and receiving information is at the heart of communication.

The roles of sender and receiver are asymmetrical. While senders (speakers) are often considered more important than receivers (listeners), in large part because speakers are often considered to be "commanders", the relationships are not that simple. Anyone who has shouted at people who can't hear or understand a message - or simply don't want to hear it - has experienced the power of the receiver.

Computing has long combined strong expectations that receivers will perfectly understand a given set of messages with a parallel understanding that receivers will fail ("Abort, retry, fail?" or some other behavior) when they receive messages beyond their ability to interpret. Programmers are very used to working with near-perfect communications inside a tightly constrained set of understandings. Changing those understandings requires explicit work - a type cast or inheritance structures, for instance.

Markup is certainly computerized communications, but it offers a very different set of possibilities than the models typically encountered in computing. While XML, for example, has severely constrained syntax, it has endless possibilities for describing labeled structures and contents.

Developers who are used to writing programs which deal with infinite possibilities stored in a limited number of containers may retreat rapidly from the infinite number of containers XML offers. In trying to return to the communications models with which they were previously acquainted, they discard most of the potential XML offered in the first place.

Markup offers a communications model that is subtly different from most programming. Messages are still crucial, and messages are still tightly structured. Responsibility for the structure of those messages is now distributed, however, and responsibility for the interpretation of those messages is now more explicitly local. Tight binding makes little sense in an environment designed for openness and extensibility.

In contrast to many other computing systems, this shift in the nature of the message opens up new possibilities in which the recipient of a message is the arbiter of its content, rather than the sender. There may or may not be agreements between senders and receivers about the structure and content of the messages; meaning is, in the end up to the receiver and whatever obligations it chooses to uphold.

This feels much more like human conversation than method-calling, and suggests that developers may want to reconsider their style of communications to embrace a wider set of possibilities rather than rushing to restrain them.