Architecture vs. building codes

On March 3, I promised [1] to provide belated comments.

[1] "Comments forthcoming"
 
http://lists.w3.org/Archives/Public/public-webarch-comments/2004JanMar/0003.
html

Here they are. Due to circumstances beyond my control, these should be taken
as a personal position, based on my experience using, making, and
implementing Web standards, with no connection to the position (if any) of
my employer or any W3C member organization.

First, I'd like to incorporate by reference my earlier message to www-tag
[2]

[2] "Differing interpretations"
http://lists.w3.org/Archives/Public/www-tag/2003Jul/0261.html

I've been following most of the TAG discussions. Often there are several
possible interpretations for some aspect under discussion, and often there
is no empirical way to decide which one is correct. Both can be correct
under specific circumstances. Such is the nature of any "architecture".

An amazing amount of work has gone into the webarch document. Good work.
Still it fails to describe what could be called an architecture.

The document in question reads more like "building codes", the sort of
things that can be universally agreed upon, and concretely argued. A room
full of brilliant architects, however, will just never agree on a single
design for anything non-trivial. Each will have a different philosophy on
how things should be described, and each a unique approach.

In other words, the W3C consensus process (wildly successful as it is in
many areas) is fundamentally the wrong way to write down "the Web
architecture".

Some concrete suggestions for changes:

1) Retitle the document. It isn't an "architecture" document as it stands. I
suggest using a synonym for "building codes".

2) Change the Abstract and Status of this document to indicate that the
scope of this particular document is things that achieved consensus within
the TAG

3) Commit to better layering through one or more follow-on documents that
describe a particular architectural philosophy. In particular, REST. It's
possible that such documents could produce dissentions. If the dissention
affects running code, it should be resolved in the "building codes"
document. If it doesn't affect code, it's a legitimate difference and should
be allowed to stand. A significant body of dissenting philosophy should
warrant a separate document to espouse the alternate view.

3.5) In particular, the following open issues would lend themselves to this
kind of resolution: (not an exhaustive list)

* httpRange-14
* contentPresentation-26
* fragmentInXML-28
* rdfURIMeaning-39
* possibly URIGoodPractice-40
* and, of course, ultimateQuestion-42 :-) 

4) Remove any non-provable statements from the document, including
"Resources exist before URIs; a resource may be identified by zero URIs"
(sec 2) There may be others.

Thanks for your time,
.micah

Received on Friday, 26 March 2004 14:39:30 UTC