I'm currently grinding away on a rework of Chapter Four of the Architecture of the World Wide Web spec that we in the TAG are supposed to be delivering as one of our prime raisons-d’etre. I think this has the potential to become a really useful document; I offer some reasons for that opinion, and a progress report on Chapter Four, with squeals of glee.
Why Web Architecture? · The Web has mostly been built by hackers, originally for hackers, and is well-known to have spread virally via the “View Source” principle: find something you like, View Source, and figure it out.
But it gets harder. All sorts of weird and wonderful things are being put onto the Web. Things that are consistent with the Web really wants to work, such as for example RSS, tend to spread smoothly and not break things. Things that aren’t, such as for example large parts of the Web Services infrastructure, tend to be spread slower and have more trouble.
So it’s important for someone to write down what the basic principles are, and put them in a well-known place where they’re easy to find. The weird thing is that nobody got around to starting the job until 2002.
Chapter Four Questions? · One of the nice things about the Web is that you can use it to deliver, well, anything, as long as we restrict “anything” to the domain of things that can be embodied in bits.
Does that mean we should deliver, well, anything?
How much pre-arrangement is required before you start sharing a new
kind of
bit-stream (NKBS) with one close colleague? With a small circle of friends?
Before
you start publishing it on the Web for all comers? If you want to define it
officially, what should be in that definition? What should you
say about
when your NKBS encounters breakage? When should you consider not
inventing at all? Should your NKBS be binary or textual? If
textual,
should it be XML? Should it be designed as a final product or
something that
can be re-used for unintended purposes? If the the former (or the latter),
what are good ways to achieve that? Should your NKBS be
composable with other formats? As in being embedded, or being an envelope?
If so, how, and if not, how to keep this from happening? Is
this NKBS presentation-oriented?
If so, should you try to separate the notions of content, and
presentation, and interaction? If not, when not? If so, how?
If you’re
using XML, should you use namespaces? If so, what kind of URIs
should you use for namespace names? Should they point at anything? If
so, what?
Suppose someone points at data in your NKBS and puts #foo on
the end, what does that mean? Suppose you want your NKBS to
include links to other old and new things (this is the Web after all),
how should you do that?
I get to try writing all this down. Not inventing anything, we have working if not perfect answers to these questions, and when there is more than one answer, we usually know the trade-offs between them. So this is purely a writing challenge; capture what we already know in a way that simultaneously is useful and says it all and isn’t too long and is readable and is exact. I’ll try to finish this off on the plane home, Thursday.
Chris Lilley and Norm Walsh are writing pieces too.
Maybe I’m weird, but I feel like a kid in a candy store.
