Sunday 12 January 2014
Web Specifications And The Frame Problem
I've noticed a pattern of mistakes when some smart people think about Web specifications. They think that a general rule in some spec does not apply to some specific situation that they're focused on, because the spec does not mention their specific situation. One example: someone suggested that we could make typed arrays returned by Web Audio APIs not be neuterable, arguing that this did not alter already-specified behavior because "nothing currently specifies how typed arrays work with Web Audio". Another example: someone argued that CSS does not specify how to determine the size of CSS content, padding and border boxes when the 'overflow' property is not 'visible'.
I hope it's clear that these are mistakes because when a Web spec states a general rule, that rule applies in all situations unless there is specific text contradicting it elsewhere (in which case, some spec should clearly indicate which rule prevails ... and I recognize that's not always true). Any other approach leads to madness; modularity and extensibility would be destroyed if, any time a feature is added to the Web platform, we had to explicitly reaffirm the behavior of all other features.
I think this is a form of the "frame problem" in AI, or "default logic". A kind of intertia requires previously specified rules to remain true until explicitly changed by another spec.
In typical programming languages, we tackle these issues by making every modifiable rule an explicit extension point (which could be implemented in lots of ways --- a virtual function call, a function value, an enum value, etc). Modifications explicitly utilize the extension point. This is sometimes done in specs, but rarely. One reason is that it makes your specs verbose and hard to read. Another reason is that it's hard to know the set of extension points ahead of time, so when you discover later you need to make modifications, you have to go back and add those extension points. That's getting easier now that more specs are using the "living standard" model, but it used to be hard.
There are programming languages that support this kind of dynamic extensibility. Languages with externally defined multimethods have a taste of it. CSS itself, ironically, orders rules by specificity and allows more-specific rules to override less-specific rules.
One problem I've been interested in for a long time is encoding the semantics of board games. Board game rules are often designed like Web specs, with some rules overriding others in special cases. Board games have extensibility problems, when expansions come out which lead to ambiguities in the context of the original game. (Munchkin makes sport of the problem.)
Comments