[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
- From: "Simon St.Laurent" <email@example.com>
- To: Marcus Carr <firstname.lastname@example.org>
- Date: Wed, 28 Mar 2001 10:55:29 -0500
At 01:07 PM 3/28/01 +1000, Marcus Carr wrote:
>This is getting silly - if you check dictionary.com it defines an expert as "a
>person with a high degree of skill in or knowledge of a certain subject". I'm
>at a loss as to who could possibly be more appropriate. You don't want rich,
>self-interested parties and now you don't want people with actual topic
>understanding either - who do you want to do the work? Experts are typically
>experts because they work in the field.
That's the obvious reason why 'experts' are given special privileges.
I'm suggesting, however, that it may be time to question whether experts,
by virtue of knowing more than the average developer, may in fact know too
To over-generalize, here's what the problem looks like:
- Experts are very good at definining processing layers.
- Experts are very good at achieving optimization by blurring those
processing layers. (They know where the benefits are, how to achieve them,
and how to stay out of trouble.)
- Those experts (perhaps that kind of expert) are willing to combine
multiple layers of functionality in a single process. They know how to
make it work safely and efficiently, and think that even the 'bozos' should
be able to figure it out.
- The result? Specifications which do too much (and sometimes, even
simultaneously, specify too little.)
I'd put XML 1.0 forward as a canonical example which has succeeded
_despite_ such problems. Did DTDs really have to be mashed into the XML
1.0 spec? Did all of that have to be _one layer_ of processing? No. Has
that helped the learning or adoption curves? I really don't think so. At
least XML tried really hard to make life easier than it had been, and for
that I think we're all quite obviously grateful.
Namespaces suffered from a similar flaw. They added substantial processing
and readability issues to documents by using the inherited attribute
mechanism, and relied on URIs, a spec that only URI experts really seem to
like. There are 'safe' and easy ways to use namespaces, but we've spent a
few years figuring out what they were. The spec seems to assume that
readers can figure that out. Yes, the foundations are simple, but not in a
way that makes much sense for a good long time. Namespaces are useful, and
maybe they'll seem obvious in five years, but they're stil pretty strange
creatures to an awful lot of developers.
I'd suggest that similar flaws afflict many of the specs coming from
various organizations, and that 'bozos' like me (aka at my programming
skill level) tend to be the unfortunate victims of the time and effort
wasting caused by such flaws.
Hence, my suggestion that we consider other approaches to
design-by-expert. It doesn't have to mean design-by-moron, but it does
require a change in perspective.
Simon St.Laurent - Associate Editor, O'Reilly and Associates
XML Elements of Style / XML: A Primer, 2nd Ed.
XHTML: Migrating Toward XML
http://www.simonstl.com - XML essays and books