Flame on language versioning and multiplexing

Here is a message that I sent to Larry Masinter and a few
others about a month ago, with the following apology attached:
"I don't know whether this flame might be of general interest, so I
hereby send it only to friends first to vet. I don't want to step into
this hornet's nest without encouragement."

In response, Larry said:

"I think this level of analysis is really valuable and I'd
encourage you to publish it. If we can come up with a clear
and open analysis of extensibility mechanisms for already
deployed languages (such as HTML of course but applicable
to other systems), I think it would be valuable to existing
controversy but also of lasting value."

On today's TAG call, Larry gave me additional encouragement,
so here is the flame, edited slightly. Be nice please - this is
work in progress.
   -Jonathan

----------

You may have seen my contribution to this discussion...

http://w3.org/mid/063031F1-1645-4A4C-A350-2DF0077B9722@creativecommons.org

usually referred to as "Jonathan's versioning formalism".

In order to have the potential to help straighten out confusions like
the present one, this formalism ought to be modified to account for
differential payoff to sender and receiver. Then we can talk about the
situation where a sender sends a message containing parts that are not
understood by the receiver, and distinguish between points in
sender/receiver payoff space with good (positive payoff), punishing
(negative payoff), or neutral (zero payoff) coordinates along the
sender/receiver axes. The payoff to the sender will shape the sender's
behavior, and the payoff to the receiver will shape the receiver's
behavior.

The payoff to the sender depends on what the receiver
does (unless communicating just "feels good" or is required by law),
but will often be indirect. E.g. in advertising,
it's not the payoff from any particular transaction that matters, but  
the
amortized payoff from many transactions.

When a message is broadcast to multiple audiences with different  
capacities, it
matters a lot whether the sender knows that this is the case. Creators
of good children's TV shows (which I hereby define to be the ones I
like to watch) know that there are two audiences and craft their
material so that both appreciate the content. Creators of bad ones
don't and only aim for one audience. But including material
meant only for grownups (positive receiver 2 payoff), perhaps disguised
or deemphasized so as not to make those who don't understand anxious
(negative receiver 1 payoff), is, to me at least,
the essence of craft and quality.

We have the same situation with content creators who only test against
a single browser, and consider any part of the content a failure that
doesn't create benefit for users of that browser. This contrasts with
standards-aware content creators, who will use a spec to predict
the outcome of interacting with browsers of unknown but spec-following
nature, and content creators who exercise "craft" or "good
practice", providing content that combines parts suitable for a
variety of audiences - those speaking multiple languages, those with
disabilities, those possessing RDFa clients. Those exercising craft
have a more difficult job in creation and testing - they have to think
- and this extra effort will only be made if the perceived benefit
outweighs the cost.

In a sense material that is knowingly destined for different audiences
constitutes multiple communications channels, and the question
of server/client compatibility (payoff) might
be better thought of not as a language extensibility problem but a
multiplexing problem. That is, if in-line language extensibility
(think: child-inaccessible puns) is outlawed, the new material will be
communicated *somehow*. (This is similar to the rewrite-based
extensibility question in
programming languages. Macros happen whether a language spec
supports them or not; it's just a question of how extensibility
will be managed - forking new languages (think: content-types), external
preprocessors, or in-language macro facilities.)

It's not clear what purpose version markers in HTML, indicating the
presence of stuff not understood by some clients, should have for
clients that don't understand that stuff. I guess it could lead to  
"upgrade
your browser" or "get this plugin" dialogs, or "save this file or
choose application", the payoff of which is the ultimate benefit minus
the annoyance of having to deal with the dialog. But in some cases
knowing that you don't understand will only lead to receiver anxiety.
Suppose I go to Peru and am spoken to in  Spanish, which I don't
understand. How can I tell how important what's being said should be to
me? Sometimes very, sometimes not; sometimes I can tell whether
it has must-understand status, sometimes I can't; in the latter case I
only have anxiety (perhaps a lot, if it's an armed soldier who's
speaking) and in a sense I might prefer to have heard nothing, like the
child who happily doesn't know that an adult pun has just flown past
in their TV show.

Jonathan

Received on Thursday, 16 April 2009 19:34:44 UTC