Last week I reviewed Weaving The Web (WTW, first paperback edition) and promised a few choice quotes. Even after picking and choosing, there were quite a few good ones. TimBL just happens to say many clever things.
Here are some choice quotes with followup commentary.
...storing the same information in two places ... is almost always asking for trouble: the files would inevitably get out of step.
While I agree, certainly in the context of bidirectional external links that require duplicated link information to function, the general principle of redundancy in systems is certainly a good thing. But systems that themselves depend on redundant information are more fragile, and thus are asking for trouble
. Redundancy should not be used for core functionality. It should however be used for performance (e.g. caches) and data integrity (e.g. replication and backups). Which brings me to the next quote:
I gave the eight-inch floppy disk to a systems manager, and explained that it [Enquire] was a program for keeping track of information. ... Eventually, the disk was lost, and with it, the original Enquire.
Certainly an example of when a little redundancy would have been a good thing (speaking from my own experiences with such losses as well of course).
The philosophy was: What matters is in the connections. It isn't the letters, it's the way they're strung together. It isn't the words, it's the way they're strung together into phrases. It isn't the phrases, it's the way they're strung together into a document.
...it isn't the documents, it's the way they're linked together into sites. It isn't the sites, it's the way they're linked together into a web.
Of course if I had insisted everyone use HTTP, this would also have been against the principle of minimal constraint. If the Web were to be universal, it should be as unconstraining as possible. Unlike the NeXT computer, the Web would come as a set of ideas that could be adopted individually in combination with existing or future parts.
This quote captures a few important principles: modularity, minimalism, and compatibility. Certainly many current W3C specifications attempt to adhere to this principle. Yet, in my opinion many of the specifications are more monolithic in nature (neither modular nor minimal), and were not designed to work well (not compatible) with either existing or future technologies. In fact some even appear to have been designed specifically to antagonistically replace existing technologies. This counter-principle, or syndrome, is better known as NIH. Joel makes some good points about when it's good to do it yourself.
In my opinion, it is usually better to at least consider current solutions to a problem before attempting something new (simply out of the principle of laziness, also known as efficiency). Sometimes being ignorant of previous solutions enables a major leap, a novel and much better solution that so-called experts were/are apparently blind to. However, more often than not, analyzing previous solutions (and their failures, or failures in progress) can help broaden an understanding of the requirements for solving the problem at hand, and perhaps even provide a headstart on a better solution.
There is almost always a better solution. The real question is, is the incremental advantage of such a better solution over a current solution worth the necessary effort to develop the better solution and the cost of dealing with the legacy of the present?
... I defined two new URI prefixes that could appear before the double slash — "gopher:" and "wais:" — that would give access to those spaces. Both systems took off much more quickly than the Web and I was quite concerned at the time that they would suffocate it.
I remember gopher having an initial surge, yet I don't remember wais ever being any sort of competition to http.
But the human readability of HTML was an unexpected boon. To my surprise, people quickly became familiar with the tags and started writing their own HTML documents directly.
This is quite humorous really, because among most web designers I've spoken with, ease of understanding content source and ease of direct authoring were critical to their own adoption of HTML, and CSS for that matter.
What's even more ironic is that I think there are still many in W3C that choose to ignore the importance of the ease of textual authoring
(though at least one or more 'get it'). In fact there's almost a kind of unspoken discrimination against text-based interfaces. Neal Stephenson's In the Beginning was the Command Line
covers the topic of how modern computer interfaces (and scientists for that matter) have forgotten the advantages of text based interfaces had.
Why, even Ian Jacobs of the W3C was recently quoted in a CNN article as saying
In an ideal world, URLs would neither be seen nor heard.
To what ideal? The speed and vigor that URLs have entered the mass lexicon, in the media, advertisements etc. should make it obvious that whether the "experts" think so or not, whether they designed them to be or not, URLs happened to be quite usable indeed (while being precise, and perhaps just "weird" enough to be memorable).
After all, How many ads do you see with "go" words on them? Or "RealNames" (yeah, remember that joke? Glad we never wasted any effort or code size implementing it in IE/Mac) Or even AOL keywords? Or some other supposedly "easier" method of addressing/accessing a website? They're all effectively irrelevant today (but boy do their inventors/founders know how to whine and place blame on everyone but themselves, and fail to admit that their ideas just sucked, like those of so many overfunded dotcoms). The market naturally chose URLs (and search engines for that matter).
The point is, ease of authoring, and the linguistic advantages of text are two very big reasons why HTML and URLs have seen the incredible adoption rate that they have over the past ten years, and CSS for the past six. Any technology seeking adoption would do well to consider these principles from the start.
The people of the Internet built the Web, in true grassroots fashion.
Grassroots and decentralized was how the Web was built, not by just one company, nor one product, nor one site.
...I had been trying to get CERN to release the intellectual property rights to the Web code under the General Public License (GPL) so that others could use it. ... while it allowed things to be distributed and used freely, there were strings attached, such that any modifications also had to be released under the same GPL. In the gopher debacle, there were already rumors that large companies like IBM would not allow the Web on the premises if there was any kind of licensing issue, because that would be too constraining. And that included the GPL.
CERN had not made up its mind. I returned from Columbus and swiftly switched my request, from getting a GPL to having the Web technology put in the general public domain, with no strings attached.
I wonder if TimBL would have used the Creative Commons if that had been around at the time. Certainly they have a quite a few licenses that have (nearly) no strings attached, like my favorite, the 'by' license also known as Attribution 1.0 which allows everyone to make derivative works, and profit from them.
... like scientists, people in the Web development community had to be ethically and morally aware of what they were doing.
More along these lines can be found at EFF and CPSR.
Despite the Web's rise, the SGML community was still criticizing HTML as an inferior subset, and proposing that the Web rapidly adopt all of SGML. Others felt that HTML should be disconnected from the ungainly SGML world and kept clean and simple.
Dale Dougherty of O'Reilly Associates ... started telling everyone that, in essence, the SGML community was passé and that HTML would end up stronger. He felt that we didn't have to accept the SGML world wholesale, or ignore it. Quietly, with a smile, Dale began saying, "We can change it." He kept repeating the phrase, like a mantra. "We can change it."
The first paragraph of that quote almost reads like something you would see today, just substitute "SGML community" with "XML community". In fact, I have heard rumors that many key players from the so-called "SGML community" have simply reappeared in the "XML community" and now instead criticize XHTML
(Why not just make up your own tags?
)
and CSS
(Everything should be written in XML! I only want one parser!
Yeah, what about all those complex attribute values that each need their own mini-parser?)
and HLink
(XLink was first and is more complete!
).
But the second paragraph is the key here. A technology that has enough advantages over the present (like being simpler) can, and will, change the present.
Philosophically, if the Web was to be a universal resource, it had to be able to grow in an unlimited way. Technically, if there was any centralized point of control, it would rapidly become a bottleneck that restricted the Web's growth, and the Web would never scale up. Its being "out of control" was very important.
I'm sure folks have asked the question whether W3C itself (and all the global DTD URLs pointing there), ironically, could be interpreted as a "centralized point of control", and thus eventually a bottleneck.
The web is more a social creation than a technical one. I designed it for a social effect — to help people work together — and not as a technical toy. The ultimate goal of the Web is to support and improve our weblike existence in the world. We clump into families, associations, and companies. We develop trust across the miles and distrust around the corner.
It's easy for technologists to forget why they're doing what they're doing. This paragraph serves as a good reminder.
lawyers do not tell computer programmers how to program
Exactly.
When I want to interact with a computer, I have to wait several minutes after turning it on before it is ready to converse. This is absurd. These machines are supposed to be there for us, not the other way around.
There really is no excuse for how long today's computers take to boot, unhibernate, unsuspend, wake from sleep etc. Computers have gotten orders of magnitude faster, and yet the times to perform the aforementioned activities haven't.
And the second point is perhaps the more important one. The machines are there for the humans, not vice versa (at least for now). We should be designing our technologies for humans first, and machines second (to be reevaluated in the context of future sentient seeming artificial intelligences).
XML makes it easy for everyone to create their own tags or entire markup languages. We might therefore see an end to the idyllic situation that has prevailed thus far on the Web — the predominance of HTML, which has helped all of us share documents easily. Can it be that, a decade into the Web's existence, XML, will give us a freedom that forcibly leads us back toward myriad incompatible languages? This is indeed a serious possibility, but one that has been anticipated.
Anticipating something does not necessarily mean you can prevent it. Worse than that, all too often I hear cries from self-proclaimed XML experts inciting developers to use XML to invent their very own tags, rather than steering them towards reusing established and already understood tag sets, such as XHTML.
Often, everything from the minutes of meetings to background research vanishes, and the reasoning that brought the group to its endpoint is lost. It might actually still exist on some disk somewhere, but it is effectively useless because the finished document doesn't link to it. What's more, different social and practical systems isolate documents of different levels from each other: We don't insert random notes into finished books, but why not, if they are relevant and insightful? ... Our policy is "If it isn't on the Web, it doesn't exist"...
The primary principle behind device independence, and accessibility, is the separation of form from content. When the significance of a document is stored separately from the way it should be displayed, device independence and accessibility become much easier to maintain. Much of this is achieved with a style sheet...
Yet, despite such a clear statement of the principle of separation of form from content, there are many people, and a few working groups even, who continue to work on purely presentational markup which inevitably ends up mixing with semantic markup, and thus making it far more difficult to apply alternative presentations for various media or accessibility needs.
The typical excuse given is, but we have to be able to do it all in XML which is of course complete crap. I've decided it's pointless to try to openly fight such efforts, relying instead on the marketplace to pick the better solutions (various flavors of semantic X(HT)ML+CSS) in the long run.
We could allow a set of working groups that can be shown to form a tight self-reliant cluster to secede and form a new peer "clone" consortium. ...anyone could start a consortium, when the conditions were right, by pushing a few buttons on the Web page of a virtual "consortium factory".
This is a fascinating set of ideas. But why a "peer" consortium? The W3C did not start as a peer to those that came before it. I think if anything, we'll see the tiniest of efforts, that start quite small, and perhaps stay small, or perhaps slowly grow into something that could be said to be a peer.
The trick here, though, is to make sure that each limited mechanical part of the Web, each application, is within itself composed of simple parts that will never get too powerful.
An excellent goal. Yet certainly one that many (if not most) of the parts defined by most W3C RECs are far from achieving. Hopefully standards proposed in the future can better heed this call for simple parts that are never too powerful.
Making global standards is hard. The larger the number of people who are involved, the worse it is.
Speaks for itself.
We are slowly learning the value of decentralized, diverse systems, and of mutual respect and tolerance.
Indeed. Perhaps someday we will even see decentralized web standards efforts.
And that's it. There are many many more illuminating quotes from TimBL which I have omitted from this summary. If you found the above quotes and commentary insightful, it's probably worth your time to read the whole book.
© 1996-2003, Tantek Çelik, All Rights Reserved
Comments: