Distributed Extensibility

Wednesday, 2009-11-05,
12:05-0800

There's been a debate in the HTML Working Group on distributed
extensibility; this led to a session at the Technical
Plenary yesterday (and, for me, an interesting lunch discussion
afterwards that led me to think about issues I hadn't before thought
much about). One issue in that debate is that some people see the
debate as a debate specifically about whether to use XML namespaces and
some see it as a debate about extensibility in general.

I've come to accept that extensibility has positive value, and that
the risk of open platforms having proprietary extensions is outweighed
by the risk of stagnation and the benefits of adopting extensions into
the platform. The value of openness just needs to stand on its own:
people can choose open extensions over proprietary ones, just like they
can choose an open core over a proprietary one. (This has similarities
to the open source vs. free software debate.)

However, I think XML namespaces have some problems as an extension
mechanism. One of the reasons I don't like them is that they're hard to
use: people have to remember obscure namespace URIs, which makes markup
harder to write. Another is that namespaces can encourage
not-invented-here syndrome: they encourage extensions to be complete
pieces rather than reusing as many pieces of the core as possible, since
once you're writing a subtree in a different namespace, it's easier to
use elements in that namespace and it's extra work to switch back into
the core namespace. Thus they can encourage extensions to extend more
than necessary.

Accepting that extension mechanisms are good doesn't necessarily mean
their value exceeds their costs; extension mechanisms, especially in
software, can be quite costly. In software, large portions of the cost
of extensibility is borne by the core, but it's not clear that's also
the case for standards.